On Thu, 16 Jun 2005 13:50:47 -0300
Rafael Espndola [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
