On Sat, Oct 05, 2013 at 11:57:43AM +0200, Miroslav Lachman wrote: > > > Baptiste Daroussin wrote: > > On Fri, Oct 04, 2013 at 02:22:52PM +0200, Miroslav Lachman wrote: > >> 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: > >> portA-bin > >> portA-doc > >> portA-dev > >> portB-bin > >> portB-doc > >> portB-dev > >> > >> 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 > >> anyway. > >> > >> 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. > > > > That is because you keep thinking you have to build those ports yourself, > > we are > > here speaking of binary packages. > > I don't think it's about building ports. It's about the list of what I > need to have installed and maintained on our systems. And with this > split to more packages, then the list will grow and tracking of changes > and dependencies will become hell like on Linux distributions. > > Miroslav Lachman
Nope still will only have to maintain the same list, the rest will still automatically be tracked, and the dependency hell we havr right know, will be simplified, because less useless dependencies, packages will have less surface for collision, pkg autoremove will keep taking care of the now unused deps, etc... regards, Bapt
pgpha4YG3DhfU.pgp
Description: PGP signature
