packaging system (was: Re: GCC 3.3.2 kernel)

[Jeroen Ruigrok/asmodai]

-On [20031030 22:02], Lewis, Todd (todd.lewis at xxxxxx) wrote:
>An excellent point, although I don't think it renders my point moot.  The
>work I have done is on systems with small storage, meant for autonomous
>operation after sale to a customer.  Nothing realtime or pure-embedded;
>sorry if I offended any of the high-priests out there.

Nah, I don't get easily offended, but I thought you were hinting at pure
embedded work.
Also, sometimes for the sake of the argument I state things rather black
and white in clear words.  That's never meant as a personal attack or
something.

>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.

>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.

>As someone who learned (at least some of) debian's facilities, I have
>benefitted from using them over the years, and I know many others who, once
>they saw what you could do with dpkg, picked it up and started benefitting
>from it as well (on debian and on solaris, osf/1, even freebsd.)  Dragonfly
>is an interesting project, and as long as you guys consider packaging within
>your scope, (which considering the practical state of packaging in the bsd
>world, I think is a good decision,) you should at least be aware of these
>experiences.  Whoever is writing the code will have to make the decisions,
>and we will all see what the result is.  I'm just trying to be helpful.

Being helpful is nice, since it gives insight from the user perspective.

Problem is that there is not a single user perspective, I personally
dread having to install 2/3 ports/packages before I can do what I do now
with just one.  But of course, you dread the fact you have to install
one big hunk of stuff, whereas you'd be just as happy with only the
binaries.

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.

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

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
Success is satisfaction with yourself...