[HEADSUP] Staging, packaging and more

Miroslav Lachman 000.fbsd at quip.cz
Fri Oct 4 12:23:05 UTC 2013

Baptiste Daroussin wrote:
> On Fri, Oct 04, 2013 at 08:00:43AM +0100, Matthew Seaman wrote:
>> On 04/10/2013 07:32, Baptiste Daroussin wrote:
>>> On the other ends, that makes the package fat for embedded systems, that also
>>> makes some arbitrary runtime conflicts between packages (because they both
>>> provide the same symlink on the .so, while we could live with 2 version at
>>> runtime), that leads to tons of potential issue while building locally, and
>>> that makes having sometime insane issues with dependency tracking. Why having
>>> .a, .la, .h etc in production servers? It could greatly reduce PBI size, etc.
>>> Personnaly I do have no strong opinion in one or another direction. Should we be
>>> nicer with developers? with end users? with embedded world? That is the question
>>> to face to decide if -devel packages is where we want to go or not.
>> Can't we have the best of both worlds?
>> We're already planning on creating sub-packages for eg. docs and
>> examples.  The default will be to install docs etc. sub-packages
>> automatically unless the user opts out in some way.  I imagine there
>> will be a global switch somewhere -- in pkg.conf or similar[*].
>> Couldn't we work devel packages in the same way? Install by default
>> alongside the main package unless explicitly requested not to.
>> I think having the capability to selectively install parts of packages
>> like this is important and useful functionality and something that will
>> be indispensible for eg. embedded platforms.  But not an option that the
>> vast majority of ordinary users will need to exercise.
>> 	Cheers,
>> 	Matthew
>> [*] The precise mechanism for choosing which sub-package bits to install
>> has not yet been written.  If anyone has any bright ideas about how this
>> should all work, then I'd be interested to hear them.
> That is another possiblity, I do prefer Erwin's idea about the -full, but this
> also makes a lot of sense.

I really like the current state with full packages. Disk space is cheap, 
full packages is default for whole FreeBSD existence and it is easy to 
maintain the system with it. If I want portA and portB, I just install 
portA and portB and if I want to see installed ports, I see two ports 
installed and not a bunch of lines like:

When I need to update those ports, I will update two ports, not six or 
more ports / sub ports.

Embedded systems are corner case, where many things need to be tweaked 

So I like the idea of default full packages with possibility to 
optionally select and install sub parts for those who really need the 
fine grained list of packages.

Miroslav Lachman

More information about the freebsd-ports mailing list