[HEADSUP] Staging, packaging and more

[Matthew Seaman]

On 04/10/2013 08:05, 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 think I was sufficiently vague about mechanism that Erwin's ideas are
compatible with what I wrote.  I know what I think the eventual
functioonality should be, but I don't really have any detailed ideas on
how to implement it.  Yet.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matthew at infracaninophile.co.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 398 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20131004/a7f18083/attachment.sig>