packaging system

[Craig Dooley]

I like the idea of standardizing everything, but I think theres two separate 
battles to be fought.  Theres the idea of package building and binary 
distribution if you ask me.  Ports currently does both, and I dont think the 
option to build from source should be taken away from the user, but a 486 
router does not want to build apache, even if they want to run it.  Making 
the port maintainers life easy should definitely be a top priority goal, but 
so should making the users life easier.  How many people want to spend the 
time compiling openoffice?  Thats about the biggest thing I can think, and 
granted, small ports take almost no more time to build than download in 
binary form, but for upgrades its much more convenient to have binaries if 
you ask me.  I think we should look at this as two separate problems.  One is 
creating packages, and the other is distribution/installation/configuration/
upgrades.

-Craig 

On Friday 31 October 2003 15:47, Chris Pressey wrote:
> On Fri, 31 Oct 2003 14:23:53 -0500
>
> Richard Coleman <richardcoleman at xxxxxxxxxxxxxx> wrote:
> > I don't think anyone is suggesting to remove such capabilities.  Just
> > give some structure (or at least style guidelines) to the method of
> > creating these.  This is already happening (slowly) in FreeBSD.
> > Portlint was just enhanced to complain if the port maintainer uses
> > variables in the USE_* namespace.
>
> Yes, that's all I meant - that the namespace be better standardized.
> Call all user knobs <portname>_WITH_<option>, or something like that.
> Maybe <portgroup>_WITH_<option>, pending definition of a "port group"
> (GNOME or KDE make some sense, other groupings might be a bit muddy.)
>
> On the topic of standardizing things, it would be extra-nice, but
> probably extra-difficult, to standardize the cached configure
> information.  I have no idea how much time is wasted just having
> seemingly every single port independently discover the maximum length of
> command-line arguments.  Surely there's a way to reduce it?
>
> -Chris

-- 
Craig Dooley											cd5697 at xxxxxxxxxx
Attachment:
pgp00010.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00010.pgp
Type: application/octet-stream
Size: 187 bytes
Desc: "Description: signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20031031/74d9361d/attachment-0020.obj>