On Thu, 16 Jun 2005 13:50:47 -0300 Rafael Espíndola <[EMAIL PROTECTED]> wrote:
> Has someone worked on changing ebuild so that it could create > many binary packages from one source? A less intrusive solution (well, i think, although it would still be an important change) would be to have some kind of special flags dedicated to a new ebuild phase: pkg_filter. Lets call them FILTER flags (i will often use the server/client example in the above, but that's just an example sure). The main differences with USE flags would be: - only work at pkg_filter time, so the would not have any influence on compile-time or the contents of binary packages - accessible through a different bash test function ("filter" instead of "use") - not recorded in binary packages metadata, so its really the target host's FILTER flags that are taken into account, and not the building host's ones - they would sound "negative" rather than "positive", there purpose being to remove things - they would be a bit simpler (probably no need to have some defaults in profiles, no auto-triggering à la use.defaults, etc.) Other than that, they would be similar (have some filter.desc and filter.local.desc, have a package.filter config file in /etc/ portage, be recorded in /var/db/pkg, add some colored output to `emerge -pv`, etc). The pkg_filter() step would happen somewhere after src_install (or binary package unpacking) and before the merge. Not sure whether it should be before or after pkg_preinst (oh, and btw, if I suggest not using pkg_preinst, that's because it really should be sandboxed). Based on this FILTER flags, pkg_filter would apply some kind of ebuild-specific contents filtering, by deleting stuffs in the the image directory. Example for openssh: pkg_filter() { if filter 'noserver' ; then rm ${D}usr/bin/sshd rm ${D}etc/init.d/sshd rm ${D}etc/conf.d/sshd ... fi } So, this proposal is really about putting in ebuilds the logic to replace some of the INSTALL_MASK or overlayed ebuild hacks. I don't think it's the right thing to put that completly on user's responsability like it is now when it's such common needs like installing a simple ssh or samba client for instance. The idea comes from rereading an old thread about server/client USE flags actually: http://thread.gmane.org/gmane.linux.gentoo.devel/13501 Some of the point made there that i think it would solve are: * splitting ebuilds into something-client and something-server is not the right approach from several maintainers point-of-view (more work on updates, lots of duplicate compile time, etc.) => FILTER flags would solve the duplicate compile workload at least. It would still give more work to maintainers tho, to write the pkg_filter() functions where needed, and to test the package in several FILTER configuration. But I tend to think that it's much less work than a split: - you keep a single ebuild - you don't have to change anything in src_*() - it's not critical if you miss some files in pkg_filter; having forgotten to delete the sshd manpage in the above example won't break anything. Neither will missing a something.so.1.0 renaming to .so.1.1 when bumping a package. All one has to take real care of is to delete only things that he is sure are used only by the package part he want to filter out, but if in doubt, the safer approach is the easiest one: not deleting the file. * USE flags are not neither the right approach (for some no-more- valid concerns, like their globalness at that time, but also for some still valid ones like "i will have to recompile the whole samba if i suddenly decide to add a client to my server") => with FILTER flags, as soon as you keep binary packages, reinstalling samba without "noclient" doesn't imply recompilation. Also, the same GRP packages will be good for both people who want a samba server and those who want a samba client. One last thing I've not talked about are dependencies. A very valid point made against a "server" USE flag was that it sometimes happen that a package can depend on foo/bar being installed with +server. The issue still holds with FILTER flags sure. But i think portage devs are working on solving that for USE flags (would be something RDEPEND="foo/bar:flag"), and if that's true, then it could easily be extended to FILTER flags too i think. Something like RDEPEND="foo/bar:!noserver" (or maybe the opposite way: don't accept any filter flag per default, and specify in dep atoms the acceptable ones). And again about dependencies, there the question whether RDEPENDs could be trimed down when filtering parts of a package (in case libfoobar is only used by a server daemon that won't be installed for instance). Here, i don't really have an opinion about whether it worths taking FILTER flag into account. Again, to much RDEPEND is not critical. But it would be possible to deal with that anyway: conditionnal RDEPENDs could be interpreted with the USE flag (the one recorded from compile-time in case of binary package) plus the target host FILTER flags, whereas DEPENDs would only take USE flags into account. And that's it. Sorry for the long email, writing it made me think of a few more things than i had to say at the beginning. -- TGL. -- gentoo-dev@gentoo.org mailing list