DragonFly BSD
DragonFly kernel List (threaded) for 2006-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: pkgsrc packaging of base?

From: Eli Green <eli@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 9 Feb 2006 09:43:19 -0500

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.

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]