[gentoo-dev] splitting one source package into many binaries

[gentoo-dev] splitting one source package into many binaries

[Rafael Espíndola]

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

Re: [gentoo-dev] splitting one source package into many binaries

[Caleb Tennis]

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

Re: [gentoo-dev] splitting one source package into many binaries

[Patrick Lauer]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] splitting one source package into many binaries

[Mike Frysinger]

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

[Brian Jackson]

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

[Yuri Vasilevski]

Hi,

On Thu, 16 Jun 2005 12:40:39 -0500
Brian Jackson <iggy@gentoo.org> 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 Ávila de Espíndola]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting one source package into many binaries

[Rafael Ávila de Espíndola]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

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 <package> should install everything 
from <package>. 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: splitting one source package into many binaries

[Duncan]

Rafael Ávila de Espíndola posted
<200506161952.16146.rafael.espindola@gmail.com>, excerpted below,  on Thu,
16 Jun 2005 19:51:54 -0300:

> X might also be a candidate, but
> I think that in this case it is better to help xorg to do the split.

FWIW, xorg is already headed in that direction.  Their next release is
intended to be dual-track, 6.9.0 in monolithic form as now, 7.0.0 will be
the same thing only modularized.  There was a bit of a discussion on that
topic here a few weeks ago (in which I asked and Donnie covered a number
of questions on the Gentoo approach to it), after Donnie pointed to the
working roadmap document for the split.  The 6.8.99 snapshot ebuilds
(hard masked for testing) are the CVS development snapshots of this in
portage, still unsplit, as it hasn't yet been split upstream, AFAIK.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: splitting one source package into many binaries

[Duncan]

Yuri Vasilevski posted <20050616132044.2b689bd3@edune.lan>, excerpted
below,  on Thu, 16 Jun 2005 13:20:44 -0500:

> 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).

The client/server thing is a concern for me here, as well, for security
reasons.  If I don't have an SSH server merged, it can't inadvertently
be turned on somehow.  SSH is apparently a dependency for something I have
merged, and currently, it includes the SSH server.  That worries me, as
it's a server component on a normally client system, and is thus a
potential security vuln.  IMO, having it there when it's not used and the
human behind the machine has no intention of running it, is just /asking/
for security issues.  It shouldn't be there in the first place. 
Unfortunately, there's no USE flag to turn it off.

Similarly with a couple of the DHCP packages I was looking at a few weeks
ago.  I normally run static IPs on a LAN behind a NAPT based router,
giving me a /bit/ more leeway in terms of security on my Linux box, but
decided to install some form of DHCP just in case.  Several of those
packages have both clients and servers, with apparently no way to only
install the client, short of hacking the ebuild.  IMO, that's not the way
it should be.  Gentoo isn't supposed to work that way, and PARTICULARLY in
this sort of instance, where getting mixed up in your configuration may
mean you start the server instead of the client, is a security risk that
simply shouldn't have to be there in the first place.

I'm sure there are other instances...

IMO as a Gentoo user...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: splitting one source package into many binaries

[Jon Portnoy]

On Fri, Jun 17, 2005 at 01:21:22AM -0700, Duncan wrote:
> reasons.  If I don't have an SSH server merged, it can't inadvertently
> be turned on somehow.  SSH is apparently a dependency for something I have

I'm all in favor of server vs. client flexibility but this 
example is kinda bogus. Assuming you don't turn it on I'd have to say the only 
way it'd get turned on is if your system is already compromised

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting one source package into many binaries

[Thomas de Grenier de Latour]

On Thu, 16 Jun 2005 13:50:47 -0300
Rafael Espíndola <rafael.espindola@gmail.com> 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

Re: [gentoo-dev] Re: splitting one source package into many binaries

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2342 bytes --]

On Fri, 2005-06-17 at 01:21 -0700, Duncan wrote:
> The client/server thing is a concern for me here, as well, for security
> reasons.  If I don't have an SSH server merged, it can't inadvertently
> be turned on somehow.  SSH is apparently a dependency for something I have
> merged, and currently, it includes the SSH server.  That worries me, as
> it's a server component on a normally client system, and is thus a
> potential security vuln.  IMO, having it there when it's not used and the
> human behind the machine has no intention of running it, is just /asking/
> for security issues.  It shouldn't be there in the first place. 
> Unfortunately, there's no USE flag to turn it off.

There is zero security risk unless you, as root, start the server.

> Similarly with a couple of the DHCP packages I was looking at a few weeks
> ago.  I normally run static IPs on a LAN behind a NAPT based router,
> giving me a /bit/ more leeway in terms of security on my Linux box, but
> decided to install some form of DHCP just in case.  Several of those
> packages have both clients and servers, with apparently no way to only
> install the client, short of hacking the ebuild.  IMO, that's not the way
> it should be.  Gentoo isn't supposed to work that way, and PARTICULARLY in
> this sort of instance, where getting mixed up in your configuration may
> mean you start the server instead of the client, is a security risk that
> simply shouldn't have to be there in the first place.

I think you have the wrong assumption here on how Gentoo is "supposed to
work".  Gentoo ships packages as close to how upstream packages them as
possible.  If you have a problem with the daemon being shipped with the
client, then complain upstream.  We have always provided the package as
determined by upstream.  Splitting packages is a waste of developer time
and also makes things much more complex dependency-wise.

If you do not want the binary for the server installed, then edit the
ebuild yourself, remove the binary, or use INSTALL_MASK.  It isn't like
we have not provided methods for you to do this yourself.  You cannot
expect us to provide for every possible scenario and still get anything
accomplished.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] splitting one source package into many binaries

[Brian Jackson]

Thomas de Grenier de Latour wrote:
> On Thu, 16 Jun 2005 13:50:47 -0300
> Rafael Espíndola <rafael.espindola@gmail.com> wrote:
> 
> 
>>Has someone worked on changing ebuild so that it could create
>>many binary packages from one source? 
> 
> 
<snip>
> 
> 
> 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

[gentoo-dev] Re: Re: splitting one source package into many binaries

[Duncan]

Chris Gianelloni posted <1119016612.13606.13.camel@cgianelloni.nuvox.net>,
excerpted below,  on Fri, 17 Jun 2005 09:56:52 -0400:

> On Fri, 2005-06-17 at 01:21 -0700, Duncan wrote:
>> The client/server thing is a concern for me here, as well, for security
>> reasons.  If I don't have an SSH server merged, it can't inadvertently
>> be turned on somehow. [] Unfortunately, there's no USE flag to turn it
>> off.
> 
> There is zero security risk unless you, as root, start the server.

I get the point, but if it's not there to be started, it cannot be
started, thru some fat-fingering on the part of a confused admin trying to
launch the client, or any other way. If it's needed, that's one thing, but
if it's not needed, it shouldn't be there.  USE flags (not split
packages, I'll absolutely agree there) are the Gentoo way to control that.

>> Similarly with a couple of the DHCP packages I was looking at a few
>> weeks ago. [] Several of those packages have both clients and servers,
>> with apparently no way to only install the client, short of hacking the
>> ebuild.  IMO, that's not the way it should be.  Gentoo isn't supposed
>> to work that way, and PARTICULARLY in this sort of instance, where
>> getting mixed up in your configuration may mean you start the server
>> instead of the client, is a security risk that simply shouldn't have to
>> be there in the first place.
> 
> I think you have the wrong assumption here on how Gentoo is "supposed to
> work".  Gentoo ships packages as close to how upstream packages them as
> possible. If you have a problem with the daemon being shipped with the
> client, then complain upstream.  We have always provided the package as
> determined by upstream.  Splitting packages is a waste of developer time
> and also makes things much more complex dependency-wise.

Gentoo Philosophy page:  "The Gentoo philosophy is to allow this user to
do what he or she wants to do, without getting in the way."

Of course, there's a practical limit to that.  However, a simple
"clientonly" USE flag on client/server combo packages such as ssh and
dhcp would appear to be entirely within the Gentoo spirit, and generally
would require no more work than is already done in support of all sorts of
other USE flags. Simply don't compile or install the server, if a separate
binary from the client, and don't include /etc/init.d server starter
scripts (like sshd) and the like, if the clientonly USE flag is set.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: splitting one source package into many binaries

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]

On Sat, 2005-06-18 at 05:17 -0700, Duncan wrote:
> > There is zero security risk unless you, as root, start the server.
> 
> I get the point, but if it's not there to be started, it cannot be
> started, thru some fat-fingering on the part of a confused admin trying to
> launch the client, or any other way. If it's needed, that's one thing, but
> if it's not needed, it shouldn't be there.  USE flags (not split
> packages, I'll absolutely agree there) are the Gentoo way to control that.

http://bugs.gentoo.org/show_bug.cgi?id=12499

Personally, I am completely against it.  It makes dependencies a
complete nightmare to work with and would add an immense amount of
complexity for the developers and also for users that aren't going to
need/use this system.

You have the tools to remove the binaries already.  Use them.

> > I think you have the wrong assumption here on how Gentoo is "supposed to
> > work".  Gentoo ships packages as close to how upstream packages them as
> > possible. If you have a problem with the daemon being shipped with the
> > client, then complain upstream.  We have always provided the package as
> > determined by upstream.  Splitting packages is a waste of developer time
> > and also makes things much more complex dependency-wise.
> 
> Gentoo Philosophy page:  "The Gentoo philosophy is to allow this user to
> do what he or she wants to do, without getting in the way."

...and you can.  You can write your own ebuild or use INSTALL_MASK.

Allowing the user to do what he wants doesn't mean that *we* have to do
it for them.

> Of course, there's a practical limit to that.  However, a simple
> "clientonly" USE flag on client/server combo packages such as ssh and
> dhcp would appear to be entirely within the Gentoo spirit, and generally
> would require no more work than is already done in support of all sorts of
> other USE flags. Simply don't compile or install the server, if a separate
> binary from the client, and don't include /etc/init.d server starter
> scripts (like sshd) and the like, if the clientonly USE flag is set.

See my comments about writing your own ebuild or using INSTALL_MASK.

It's always easy for someone to suggest how "easy" something may or may
not be when they aren't the one that has to do the work... ;]

We have provided methods for you to accomplish what you want.  You do
not want to use them or do not find them adequate.  I can understand
that.  You need to understand, however, that we simply might not make
any changes because we feel what we have provided is adequate and don't
feel like taking on the extra work required to change the hundreds of
packages in portage that this would affect.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: Re: splitting one source package into many binaries

[Duncan]

Chris Gianelloni posted <1119281987.13606.26.camel@cgianelloni.nuvox.net>,
excerpted below,  on Mon, 20 Jun 2005 11:39:47 -0400:

> On Sat, 2005-06-18 at 05:17 -0700, Duncan wrote:
>>
>> I get the point, but if it's not there to be started, it cannot be
>> started, thru some fat-fingering on the part of a confused admin trying to
>> launch the client, or any other way. USE flags (not split
>> packages, I'll absolutely agree there) are the Gentoo way to control that.
> 
> http://bugs.gentoo.org/show_bug.cgi?id=12499
> 
> Personally, I am completely against it.  It makes dependencies a
> complete nightmare to work with and would add an immense amount of
> complexity for the developers and also for users that aren't going to
> need/use this system.
> 
> You have the tools to remove the binaries already.  Use them.

I didn't realize it had been bugged to death.  I guess others have said it
before, and everybody's likely very tired of the rehash, so despite my
opinions, I'll just shut up, now... =8^]

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: splitting one source package into many binaries

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> The 6.8.99 snapshot ebuilds
> (hard masked for testing) are the CVS development snapshots of this in
> portage, still unsplit, as it hasn't yet been split upstream, AFAIK.

The splitting is underway. Most of the protocol headers and libraries
are working, and the server itself is underway.

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCt6oBXVaO67S1rtsRAqkbAJ0aav6kr7nqW0OTmDQvUyy/h02sVQCg4zTD
LM7kUlyz4jOD4k4e5sMrZPI=
=PiTY
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list