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: matt...@infracaninophile.co.uk
signature.asc
Description: OpenPGP digital signature
