Re: [gentoo-dev] splitting one source package into many binaries
Thomas de Grenier de Latour wrote: 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? 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. GLEP it, write the code, get it approved. I really don't think there are as many people as some of you seem to think that are struggling with this night and day. --Iggy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting one source package into many binaries
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 comp
Re: [gentoo-dev] splitting one source package into many binaries
Em Thu 16 Jun 2005 14:05, Patrick Lauer escreveu: > It depends on your point of view. > Having to install 142 -devel packages just to be able to compile $foo is > quite frustrating - I prefer the Gentoo way. I agree. I think that by default emerge should install everything from . My idea is to teach ebuild how to split binary packages but install all of then by default. For example, emerge gcc would install all parts of gcc that are selected by the use flags (gcc proper, g++, libgcc, etc). But now one could do "emerge -C g++". > I don't know if there is a demand for this, but if you really need to > shrink stuff, create your own ebuild overlay with "fixed" ebuilds ... I do that right now. I was wondering if someone else would also be interested. > Well ... it gets you all kinds of problems because if you split packages > (e.g. X --> X + X-headers) and you want to compile something you'll pull > in the second package anyway. So for most packages I think it's not > really useful. Qt is the package that made me think about the problem. Maybe some client/server split in packages like ssh. X might also be a candidate, but I think that in this case it is better to help xorg to do the split. > wkr, > Patrick Rafael pgpegR0BJFwXs.pgp Description: PGP signature
Re: [gentoo-dev] splitting one source package into many binaries
Em Thu 16 Jun 2005 14:01, Caleb Tennis escreveu: > On Thursday 16 June 2005 11:50 am, Rafael Espíndola wrote: > > Is this a bad idea or simply not the Gentoo way? > > The idea isn't bad, but the implementation is more work to maintain than > it's probably worth. > > You can, of course, always roll your own ebuild variation and keep it in > your portage overlay directory. Or, alternatively, you can just "rm > -f /usr/qt/3/bin/designer". I use the rm option currently. A overlay has the disadvantage that I would miss updates to the portage tree. > Caleb Rafael pgp8Scr7U6DKK.pgp Description: PGP signature
Re: [gentoo-dev] splitting one source package into many binaries
Hi, On Thu, 16 Jun 2005 12:40:39 -0500 Brian Jackson <[EMAIL PROTECTED]> wrote: > Rafael Espíndola wrote: > > I am using Gentoo to build some small systems. While things like the > > minimal useflag is a joy, the monolithic nature of most gentoo > > packages is a headache. > > > > Kde has been spit and libstdc++ can be installed without gcc but there > > are many other packages that don't have this feature. For example, > > installing qt also installs qt designer. > > Use INSTALL_MASK to keep it from getting installed. Keep both pieces. I think that it's not the way to go because this will create the exact problem that existed with installing an incomplete kde before there where split ebuilds for it. And this problem is that when you emerge a package it expects it's dependencies to have the things it'll use form them. And with INSTALL_MASK you brake this assumption in a way that there is no easy way for an ebuild to verify that it's dependencies have installed the things that the package needs. So I think it may be good for some packages to be split in several packages (but right now I can't think of any), but I think it'll be much better introduce more granularity into many ebuils with use flags. This is specially the case (in my opinion) of packages that can have both client and server functionality (the best example I can think of is net-fs/samba, which I mostly use just to mount shares form other servers). Just my 2 non convertible (i.e. non developers) cents. Yuri. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting one source package into many binaries
Rafael Espíndola wrote: I am using Gentoo to build some small systems. While things like the minimal useflag is a joy, the monolithic nature of most gentoo packages is a headache. Kde has been spit and libstdc++ can be installed without gcc but there are many other packages that don't have this feature. For example, installing qt also installs qt designer. Use INSTALL_MASK to keep it from getting installed. Keep both pieces. Has someone worked on changing ebuild so that it could create many binary packages from one source? Something similar to debian's dpkg-buildpackage. For example, it would be wonderful to be able to do ebuild qt-something.ebuild split-package and have in /usr/portage/packages a package for qt-designer and a package for the rest of the library. Is this a bad idea or simply not the Gentoo way? Thanks for any comments -- Rafael Ávila de Espíndola -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting one source package into many binaries
On Thursday 16 June 2005 12:50 pm, Rafael Espíndola wrote: > libstdc++ can be installed without gcc that's a bad example, we're debating what to do with the package seeing as how many never wanted it in the first place -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting one source package into many binaries
On Thu, 2005-06-16 at 13:50 -0300, Rafael Espíndola wrote: > I am using Gentoo to build some small systems. While things like the > minimal useflag is a joy, the monolithic nature of most gentoo > packages is a headache. It depends on your point of view. Having to install 142 -devel packages just to be able to compile $foo is quite frustrating - I prefer the Gentoo way. > Kde has been spit and libstdc++ can be installed without gcc but there > are many other packages that don't have this feature. For example, > installing qt also installs qt designer. I don't know if there is a demand for this, but if you really need to shrink stuff, create your own ebuild overlay with "fixed" ebuilds ... > Has someone worked on changing ebuild so that it could create many > binary packages from one source? Something similar to debian's > dpkg-buildpackage. For example, it would be wonderful to be able to do > > ebuild qt-something.ebuild split-package I haven't heard of anyone trying this, and as far as I can remember it has usually been shot down as a bad idea. > and have in /usr/portage/packages a package for qt-designer and a > package for the rest of the library. > > Is this a bad idea or simply not the Gentoo way? Well ... it gets you all kinds of problems because if you split packages (e.g. X --> X + X-headers) and you want to compile something you'll pull in the second package anyway. So for most packages I think it's not really useful. wkr, Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] splitting one source package into many binaries
On Thursday 16 June 2005 11:50 am, Rafael Espíndola wrote: > Is this a bad idea or simply not the Gentoo way? The idea isn't bad, but the implementation is more work to maintain than it's probably worth. You can, of course, always roll your own ebuild variation and keep it in your portage overlay directory. Or, alternatively, you can just "rm -f /usr/qt/3/bin/designer". Caleb -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] splitting one source package into many binaries
I am using Gentoo to build some small systems. While things like the minimal useflag is a joy, the monolithic nature of most gentoo packages is a headache. Kde has been spit and libstdc++ can be installed without gcc but there are many other packages that don't have this feature. For example, installing qt also installs qt designer. Has someone worked on changing ebuild so that it could create many binary packages from one source? Something similar to debian's dpkg-buildpackage. For example, it would be wonderful to be able to do ebuild qt-something.ebuild split-package and have in /usr/portage/packages a package for qt-designer and a package for the rest of the library. Is this a bad idea or simply not the Gentoo way? Thanks for any comments -- Rafael Ávila de Espíndola -- gentoo-dev@gentoo.org mailing list
