DragonFly users List (threaded) for 2004-12
Re: The ports-system and userland in general.
On Thu, 16 Dec 2004, Weapon of Mass Deduction wrote:
> Magnus Eriksson wrote:
> > Please think of a system that does not depend on magic Makefiles. Make
> > a specification that anyone can implement, be it with 'make install' like
> > command-line tools, graphical package selection or whatever. Just leave
> > room for smart implementations you haven't thought of yet.
> I am certainly thinking about that too. However, much software today
> comes with those nasty makefiles, sadly...
> Though we could of course replace their functionality. But that might
> be a bit too ambitious in this stage. ;)
> > Separate out building packages from package management, if at all
> > possible. You should be able to walk the dependency tree (and configure
> > packages) before anything gets written to disk.
> I do not understand what you exactly mean by this. In which way you
> would say the building process interferes package management or vice
> versa, or in which way is it cluttered with the package management or
> vice versa?
I'm not sure I understand what you wrote either. :-)
But basically what I meant in those two paragraphs is that package
management should be completely separate from package building. I.e, the
same basic system should work for both binary and source packages;
fetching a binary package should be logically equivalent to fetching and
compiling a source package; and handling dependencies, installing packages
should be separate from the fetching / compiling step. (Put another way,
please, please, please, no recursive makes.)
I guess this is where someone will tell me why it can't be done.
In the first paragraph, I don't mean that we should try to have our own
replacement for Makefiles for building from source, that would be stupid.
> > For binary packages: Always have a minimal build, as well a typical
> > build ("Surely, *everyone* wants OpenGL support in their xmms...").
> > For "some compiling required" packages: Have minimal and typical
> > configurations that can be selected, as well as letting the user
> > customize. And list options relevant for the package! (with/out X11,
> > Truetype ...) I'm thinking maybe checkboxes?
> Well, that could a be realized with pkgsrc and its likes. But, as I
> already wrote in my posting before this one, it is merely a problem
> of the software packages of today that they leave no clear separation of
> compilation and configuration. Which makes it, as far as I can tell,
> impossible to do a 'minimal build' on the usual, fully compiled binary
Well, it can sort of be accomplished with pkgsrc. Before the configure
step, you'll usually get an on-screen message saying "The following flags
may affect the build of this package; USE_X11", or something similar,
scrolling by. I think the ports system is better in this regard, with the
menu thingy that some packages gives you.
> > If possible, the package system should be portable. If not possible,
> > make it work on DF instead of sacrificing good features. For "all other
> > platforms" there's already pkgsrc..
> Portability came into my mind today in fact. :)
> But define portability... UNIX? Or more?
> More might be possible, at least I already thought a bit about it
> and see no unovercomable obstacles. But would it be useful?
> The packages distributed by systems like pkgsrc are UNIX-only,
> as far as I know. And those are the ones we would be primarily
> interested in.
IMHO it would be too hard trying to extend the package system beyond
UNIX-like platforms. But then if it can be done, why not? If you have a
clean separation, the dependency handling should be similar across
platforms, even if the building part isn't.
> > Dependencies.
> > There's two sides to this argument, but personally I'd like to see
> > dependencies being specified only in terms of capability / major versions
> > / API revisions. The other, IMO, is forcing dependencies to be of the
> > "best" version (for example security-wise). In my opinion, depending on
> > specific versions just ties packages tighter together and makes it harder
> > to replace just a single one, and you'll have a bigger and bigger mess as
> > the package collection grows. On the other hand, this shifts more
> > responsibility to the user having to keep track of which versions work
> > well..
> As a wrote more times: mostly the one thing doesn't exclude the other. :)
It should. I'd prefer a strict adherence to one or the other, so that
at least you'll know what to expect. Preferably minimal dependencies, and
then having security checks separate. Maybe I'm misunderstanding you
> I had a software system in mind that lets users determine this
> themselves. This way problems with dependencies can and will be reported
> to the authors of the software in question, instead of the 'porters'.
> Of course, reasonable predefines should be shipped when requested to...
Won't work. Say I'm the author of "SnazzyMusic" (currently at version
1.2.3). One day comes a report that SnazzyMusic (version 1.1.1) won't
build on ObscureBSD because of a conflict with ClosedSSL. What should I
do? Why should I care? It works just fine on my Linux box, after all.