[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New package managment (fbsd ports)
Erik <firstname.lastname@example.org> writes:
> the ports schema is very simple. It's almost exactly what's been discussed as
> far as I can tell :) either I'm mistaken about what was discussed, or you're
> mistaken about ports.
It could of course be true that my understanding of the ports system
is wrong, I never use it, but I have read a bit about it.
> To implement download helpers, we need to know what dependancies have to be
> The easiest fastest way to do this is to have packages register
> into a database and then the auto-loader queries that database.
No, this would fail if I had installed the library myself or if I use
the library, which came with the distribution. I would be forced to
always use the port system, that inacceptable.
> That's how debian does it, that's how redhat does it, that's how
> fbsd does it,
All three, if I understand correctly, are package managers, fbsd uses
just a source based package system. But what we need is a download
helper *not* a package system.
Debian has all we need, but as it is a distribution, things go slowly,
it takes some time before the packages are build and uploaded to the
ftp servers. What is needed is a thing which does not rely on some
central organisation and it should also not require anything special
stuff to be installed (like a /usr/port or a package database).
> the only
> alternative I can see is to attempt to compile and if it fails on that package,
> assume the package isn't installed.
Thats what configure does and it does that very well.
> A ports makefile just contains what the package is, what it depends on, where
> to get it, and anything special (for packages that don't compile out of the
> box), and a convenient .include for all the behind-the-scenes stuff.
> The ports maintainer makes a makefile, an md5 file, and a couple small
> description files (a one-liner and a breif synopsis). They also slap together
> any patches needed to make it compile out of the box. That's very simple for
> the maintainer.
As said the ports system would need a central maintainer, but thats
were it fails. If we need some central maintaining, than we could just
sit back until the distros create the apropriate debs and rpms.
> The end user cd's into the right directory, and types "make install" and that's
Sorry, but thats not the way it should go.
> If they want it gone, it's "make deinstall". "make fetch" just downloads
> the file. "make" will fetch and compile, but not install/register. 99% of what
> "normal" people will do is "make install" and "make deinstall". I think that's
> a lot simpler than "./blah.sh && ./configure <parms> && make all install" for
> the end user?
No, ./configure && make && make install is what is mostly in use at
the moment, anything that would break that scheme is not good.
All we need is a tool to download the required stuff, probably in a later step
something to build the stuff.
So in practise:
checking for ClanLib... no
checking for Hermes... no
Want to download Hermes from http://www... [yes/no] yes
downloading Hermes.................... finished
Want to continue download or first build hermes? [download/build hermes] download
Want to download ClanLib from http://www... [yes/no] yes
downloading ClanLib................... finished
Want to download Pingus from http://www... [yes/no] yes
downloading Pingus.................... finished
All required libraries have downloaded, you can now build them.
At the moment I have no idea if it is a good idea to integrate the
build process into autoload, since some user may want to build the
libs themself and it is allways a good idea to keep things seperated.
Ingo Ruhnke <email@example.com> http://home.pages.de/~grumbel/ |