Is it possible to eliminate the pain to maintain make-config
switchable plist entries?
Maybe with a AUTO_PLIST=yes or something like that, firstly install
everything to ${STAGEDIR}${PREFIX} then move everything to ${PREIX}?
this is similar to homebrew, except for that homebrew ln -s everything
instead of moving them.2013/10/5 Mathias Picker <mathias.pic...@virtual-earth.de>: > Am Samstag, den 05.10.2013, 11:57 +0200 schrieb Miroslav Lachman: >> >> 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. > > +1 > > Mathias > >> >> Miroslav Lachman >> _______________________________________________ >> freebsd-ports@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ports >> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
