DragonFly kernel List (threaded) for 2003-10
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: packaging system (was: Re: GCC 3.3.2 kernel)
>>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
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]