Re: pkgsrc packaging of base?

[Eli Green <eli@xxxxxxxxxxxxxxxxxxx>]

On Thu, Feb 09, 2006 at 03:22:03PM +0100, Simon 'corecode' Schubert wrote:
> On 09.02.2006, at 14:54, Eli Green wrote:
> > > i'm opposing the packaging of base, yet i'd like to see file 
> > > registration (also for what somebody might call "package":  sendmail, 
> > > bind, whatever, basically what we have as WANT_* or NO_* already), so 
> > > that stale files can be removed and unneeded parts not be built.
> > What about making things like bind and sendmail packages? Even more
> > relevant would be non-blessed versions of GCC in my mind since they're
> > large, slow to download and compile and most people will probably stick
> > with whatever's in base.
>
> What is the gain?  Making stuff more complex for the user and more 
> complex for the developers to handle.  Maybe we are talking about 
> different things tho, and as long as nobody puts together a design 
> proposal, we will continue to do so...

Well, in the GCC example, I think having two compilers in the system
could be argued to be adding complexity. It certainly adds to compile
times for people who do source upgrades (naturally, you can just exclude
then in make.conf).

But that's sort of a dumb example since I don't think the plan is to
always include two versions of gcc. Right?

In the case of something like bind, where there's the potential to have
a very small percentage of a user base actually running it, you gain the
advantage mentioned by others; for people who do want to run it, it's
easier to upgrade a package than to rebuild your base system. If there's
a security update, the DragonFly team isn't involved in having to
release a patch, you just need a new package.

> > I guess what I'm saying is that I also see disadvantages in slicing up
> > "base" into packages, but trimming stuff from base doesn't seem like 
> > too bad an idea.
>
> I don't think we are talking about trimming stuff from base, we are 
> talking about making things optional to install/deinstall, right?

Right. But I'm with you; I like base as it is. I'm advocating not doing
that, but rather the possibility of reviewing what should and shouldn't
be included in base.

Similar to the way FreeBSD 5 stopped including perl, other "contrib"
software could be given the same treatment.