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.
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matt...@infracaninophile.co.uk
signature.asc
Description: OpenPGP digital signature
