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. regards, Bapt
pgpm7jAyrox3z.pgp
Description: PGP signature