packaging system (was: Re: GCC 3.3.2 kernel)

[ibotty]

>>My argument is that a) some people need fine-grained control over what
>>gets installed, for storage-resource resons and others, and b) other than
>>not being what you're used to, fine granularity has very little cost.
> 
> True, fine grained control is nice, but it also means that those
> depending on header files and such now need to install 2 ports/packages.
> And if you also split off additional documentation it boils down to
> 3.

this is, where the package system should come into play.
turn a knob, and you allways get the -dev and -doc packages (if they exist).
writing this mechanism is a no-brainer, it just needs to be on our
feature-list.

>>To straw-man how this argument seems to go, here's my take on the
>>old-timer berkeley critique of debian:
>>
>>"a) Everything should be done my/the-bsd/the-one-true way.  b) Therefore,
>>it's not worth it to build machinery to allow people to do things other
>>ways.  c) And plus, the way that debian does things by default is not my
>>way, therefore it's broken.  d) And plus, vis-a-vis (b), since debian's
>>machinery is unnecessary, I'm not going to learn it. e) Because of (d),
>>debian can't accommodate my needs, even though it actually can."
> 
> That's a good reasoning how most people would do away with other
> solutions.  The argument can be reversed in some ways as well, that you
> are forcing people for whom the entire solutions has worked/been working
> for all this time you are now pulling the rug from under their feet.
> 
> Also the problem with the naming of -devel for packages is that it could
> also be understood as the latest CVS/development of that piece of
> software.

yes, a guideline on naming packages is certainly needed.
say, 
includes and static libraries go to -dev,
documentation goes to -doc,
latest cvs goes to -cvs,
latest development release goes to -unstable.

it is all about consistency.

> I wonder about something:
> 
> how easy would it be to make two or three seperate plists?  One for the
> libraries/binaries/run-time, one for the documentation, and one for the
> header files and other development stuff.
> That way you could, through your application, specify what you want to
> install.  Personally, having just thought of this idea, I see this as a
> better solution, since you don't need to create 2/3 different
> ports/packages, but rather the standard which instead of 1 package
> listing now has three to allow finer grained control.

this is exactly what debian (and some rpm-distributions) do.
they just split the (one) package into three.

this has some advantages:
packages are way smaller.
(e.g.: libfreetype6 340,9kB, libfreetype6-dev 676,1kB)
dependency management is easier.
(if you install -dev, you know, you need libc6-dev and zlib1g-dev, how could
the package manager know if this is installed without -dev packages.
only with additional hooks.)

> That way, as I see it, you satisfy most users as well as not burden the
> package creators overmuch.

as this is more or less debians approach, we seem to agree on this ;)

~ibotty