Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 209653 - Request for an per-package file to drop dependencies
Summary: Request for an per-package file to drop dependencies
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High enhancement with 2 votes (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 155723
  Show dependency tree
 
Reported: 2008-02-11 13:08 UTC by Martin Väth
Modified: 2024-01-03 19:46 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Väth 2008-02-11 13:08:20 UTC
It happens not so seldom that a package pulls in some dependency which is
somewhat optional but for some reason not treated with a use flag. Examples:

  1. acroread-8.* pulls in seamonkey-bin on amd64 and openldap if used with the
ldap flag although both are not really needed (only some functions will not be
available).
  2. Meta-packages like kde-meta or texlive pull in huge dependencies for which
perhaps most but not all are desired by every user.

The current possible solutions for these unwanted dependencies are:
  (a) Convince the ebuild maintainer to introduce a use flag. This is not good,
because it is unnecessary work for the ebuild author just to have a trivial
additional case. Moreover, it leads to an explosion of the number of local use flags (e.g. for texlive (meta) ebuild this has happened).
  (b) Put the ebuild in an overlay and patch it. This is not good, because
also this is somewhat unnecessary work for a trivial thing. Moreover, it has to
be repeated for each upgrade.
  (c) In case of 2. (meta-packages) you can of course just omit using the meta-package and emerge each dependency manually. This is not good, because you
end up with many entries in the world file when you actually mean something
like "kde-meta but not ... and not ...". Moreover, in case of 1. this is no
solution at all.
  (d) Put the package in /etc/portage/profiles/package.provided or install a "dummy" package. This is not good, because this is a global change:
E.g. if openldap is "package.provided" to avoid the acrobat reader problem,
emerge will not tell you about problems when you install a package which
*really* needs openldap.

A better solution to this problem (especially w.r.t. (d)) would be if portage
would support a local file, e.g. /etc/package.provided_dependency
which is analogous to /etc/package.use but which does not contain useflags but
dependencies which are removed from the corresponding package.
For example, lines like

  app-text/acroread www-client/seamonkey-bin-1.1.8 net-dns/openldap-2.0
  app-text/texlive dev-tex/feynmf-1.0

in this file should cause that the corresponding packages are not pulled into
the dependency tree by the acroread and texlive DEPEND/RDEPEND. However, the
packages might still be pulled in as dependencies of other packages, e.g.
if openldap is needed by some system package or if some dev-texlive/* euild
needs feynmf.
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2008-02-11 13:16:01 UTC
Uh, how about moving to Bug 144480 instead of extending the package.provided hack - that's NOT intended to work around unwanted dependencies at all anyway, but plain should only be used for things you have yourself installed by other means than using an ebuild, not for pretending that you have installed something you have not.
Comment 2 Martin Väth 2008-02-11 14:29:06 UTC
(In reply to comment #1)
> Uh, how about moving to Bug 144480 instead

I see no relation with bug 144480, especially not for problems like 1.
(I only mentioned the meta-package case 2., since IMHO this would be a
nice side-effect. However, this is not the main point of the suggestion).

> extending the package.provided hack

The suggestion has nothing to do with package.provided:
It seems that this is a misunderstanding
(I change the summary to make this clearer).

> but plain should only be used for things you have yourself installed by
> other means than using an ebuild

I completely agree.
That's why the package.provided is the wrong place for such things
(although it is currently sometimes misused for it since other alternatives
are currently lacking).

This is why I suggest a "clean" way to get rid of these unwanted
dependencies (namely a "per-package" file - nothing global).
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2008-02-11 15:31:03 UTC
(In reply to comment #2)
> I see no relation with bug 144480, especially not for problems like 1.
> (I only mentioned the meta-package case 2., since IMHO this would be a
> nice side-effect. However, this is not the main point of the suggestion).

User sets are clearly a solution for your metapackages issue, in fact the metapackages will go to /dev/null once the sets are available... 

The rest of use cases here is a horrible misuse of the feature and more reasons for it to die, as opposed to extending it for even more whacky misuse (such as pretending the package is already there for ebuild A, while telling ebuild B (which A might even depend upon) that the provided package actually is not there. 

> This is why I suggest a "clean" way to get rid of these unwanted
> dependencies (namely a "per-package" file - nothing global).

This is no 'clean' way, that's a order-of-magnitude more nasty hack than the current limited feature set in package.provided. Additionally, plain nightmare wrt dependency resolver.
Comment 4 Martin Väth 2008-02-11 16:04:39 UTC
(In reply to comment #3)
> User sets are clearly a solution for your metapackages issue

Once more: This is not my main concern.
(I already regret that I have mentioned this possible application).

> The rest of use cases here is a horrible misuse of the feature

Which feature? Currently there is no feature.

> (such as pretending the package is already there for ebuild A,
> while telling ebuild B (which A might even depend upon) that the provided
> package actually is not there.

Which exactly reasonable if ebuild B needs the package unconditionally
while for eubild A the package provides only an extension of functionality
which the user does not want.

Do you prefer the current situation that user's hack wildly around the
ebuilds, install dummy packages, or misuse package.provided?
Or what is your solution of the problem?

> This is no 'clean' way, that's a order-of-magnitude more nasty hack than the
> current limited feature set in package.provided.

My suggestion corresponds exactly to /etc/portage/package.use.
This is exactly the same situation: You might want -gnome for package A
but +gnome for package B which might depend on package A.

> Additionally, plain nightmare wrt dependency resolver.

Not at all. Actually, it would be rather easy to implement:
The algorithm for building the dependency tree does not need to be touched.

Indeed, the first time the (R)DEPEND of a package is read, i.e. *before*
that data will be put into the internal structure (which will later be
used by the dependency resolver), portage could compare with the content of
the corresponding config-file and simply drop (i.e. not insert into the
internal structure) the corresponding dependency for that package.
Comment 5 Jakub Moc (RETIRED) gentoo-dev 2008-02-11 16:19:39 UTC
(In reply to comment #4)
> Do you prefer the current situation that user's hack wildly around the
> ebuilds, install dummy packages, or misuse package.provided?
> Or what is your solution of the problem?

Either convince the maintainer to make the dependency optional, or maintain your  own ebuild in your own overlay. Do *not* pretend there's some dependency installed when it's clearly not the case, as already noted, that's not what package.provided should be used for at all.

>> (such as pretending the package is already there for ebuild A,
>> while telling ebuild B (which A might even depend upon) that the provided
>> package actually is not there.

> Which exactly reasonable if ebuild B needs the package unconditionally
> while for eubild A the package provides only an extension of functionality
> which the user does not want.

If $foo provides only an extension of functionality for package A, then it should be a use flag (metapackages excluded here, you are free to not use them, they are for convenience only and a temporary replacement for missing package sets feature).

> > This is no 'clean' way, that's a order-of-magnitude more nasty hack than the
> > current limited feature set in package.provided.
> 
> My suggestion corresponds exactly to /etc/portage/package.use.
> This is exactly the same situation: You might want -gnome for package A
> but +gnome for package B which might depend on package A.

No, it doesn't correspond to that at all. While I might legitimately want USE=gnome for A and USE="-gnome" for B, this will be perfectly fine and transparently handled by the ebuild. OTOH I can't either want $foo installed for A or not installed for B - since it first doesn't make any sense (either I want $foo installed or I don't and then I should package.mask it); and second $foo can either be installed or can be not installed, boolean logic. I can't toggle its state between installed for A and not installed for B without anything actually changing on the live filesystem.

> Indeed, the first time the (R)DEPEND of a package is read, i.e. *before*
> that data will be put into the internal structure (which will later be
> used by the dependency resolver), portage could compare with the content of
> the corresponding config-file and simply drop (i.e. not insert into the
> internal structure) the corresponding dependency for that package.

Not you are even inconsistent with your own suggestion since you want per-ebuild package.provided stuff, and later on you don't want that to be honored when it doesn't make sense. Well, the suggestion itself is broken for the reasons noted above.
Comment 6 Martin Väth 2008-02-11 17:37:48 UTC
(In reply to comment #5)
> Either convince the maintainer to make the dependency optional, or maintain
> your  own ebuild in your own overlay.

So the solution is hacking ebuilds over and over and over... or convincing
somebody else to do it for you? IMHO it is the computer which should do
the routine work.

> If $foo provides only an extension of functionality for package A, then it
> should be a use flag

In an ideal world: yes.
But there are too many cases where this could be useful.
In the current portage tree this is a complete illusion.
It would probably require the number of local use flags to be doubled or
tripled.

> No, it doesn't correspond to that at all. While I might legitimately want
> USE=gnome for A and USE="-gnome" for B, this will be perfectly fine and
> transparently handled by the ebuild.

And when I might legitimately want the dependency on gnome-libs for A but
not for B this is also perfectly fine and should be transparently handled
by portage.

> OTOH I can't either want $foo installed

Not:     "...want $foo installed"! 
Instead: "...want ebuild X to depend upon $foo"

Of course, if at least one package depends upon $foo (*after* taking the
suggested new config-file into account), then $foo must be installed.

> want $foo installed or I don't and then I should package.mask it);

...which is certainly reasonable for e.g. a package like openldap on a
single-user desktop but currently not possible if the user wants to use
acroread with the annotation feature (although this feature does not need
openldap). I could name many of such examples.
Especially for indirect dependencies such cases occur frequently:
For installation of package A some package B is needed which has a huge
dependency tree, none of which you do want, but without these dependencies B
will work only very rudimentary (but sufficiently for package A). Of course,
you cannot seriously suggest the maintainer of package B to provide
an "install-me-almost-not-working" useflag. But it is certainly cleaner to
cut in such a case the undesired dependencies in B instead of hacking the B
ebuild manually (especially since the former can survive an upgrade of B if necessary).

> Not you are even inconsistent with your own suggestion since you want
> per-ebuild package.provided stuff

I was never inconsistent with the suggestion; perhaps my explanation was
not clear enough in the beginning:
My suggestion is to provide a transparent mechanism to drop a dependency from
an ebuild without the need to hack the ebuild (and more important: ...without
the need to repeatedly hack each upgrade of the ebuild).

Once more: This is rather different than package.provided.
(I just had mentioned "package.provided" in the beginning, since I thought
that the explanation would be clearer with it. I am sorry that apparently
the opposite was the case).
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2008-02-11 17:49:59 UTC
Well, good that you've snipped the most important part of my previous reply. So, once again:

<snip>
$foo can either be installed or can be not installed, boolean logic. I can't
toggle its state between installed for A and not installed for B without
anything actually changing on the live filesystem.
</snip>

Your suggestion is *exact* opposite of the above logic; you are asking for the package manager to be pretend that something is there and pretend that it's not there at the same time.

For the rest - seriously, maintain your own ebuild if you dislike the current ones due to dependencies or whatnot, instead of requesting hacks since you are  unwilling to do the legwork. Package managers are there to work with ebuilds and use information provided by them, not to invent ways how to hack-around them. If you dislike a way something is packaged, repackage it instead of requesting completely inconsistent behavior to be introduced in package managers.
Comment 8 Alec Warner (RETIRED) archtester gentoo-dev Security 2008-02-11 17:55:51 UTC
Jakub, stop arguing with the user.

So the problem you want to solve is that an ebuild provided by $SOMEONE_ELSE has metadata you don't want.  You claim that modifying the ebuild every bump is...difficult?  I think automating a bump to remove things from DEPEND would not be that complicated.

I think adding an interface to allow a user to change an ebuild's metadata is an odd move (basically what you are asking; if this is implemented you might as well make it generic enough to modify any metadata key).  The idea sounds like most ideas; extremely powerful and extremely dangerous.

It would require metadata cache changes and make portage slower (+1 stat per lookup, and a read if the mtime is old).   Not a bit deal though.  It would possibly make debugging a bitch though; I am unsure how we could make the changes visible so that it would be obvious during debugging.

-Alec
Comment 9 Martin Väth 2008-02-11 18:58:44 UTC
(In reply to comment #8)
> So the problem you want to solve is that an ebuild provided by $SOMEONE_ELSE
> has metadata you don't want.  You claim that modifying the ebuild every bump
> is...difficult?

It depends on the number of packages which you had patched this way.
Automating this by a script is practically impossible, since the (R)DEPEND
syntax is rather cumbersome and, moreover, the corresponding strings do not
always occur directly in the text but are only calculated implicitly or even
in some eclass.
So the "natural" place for automated modification is not the ebuild itself
but the place where this data is interpreted, i.e. portage.

> I think adding an interface to allow a user to change an ebuild's metadata
> is an odd move (basically what you are asking; if this is implemented you
> might as well make it generic enough to modify any metadata key).

Yes; although (R)DEPEND and SRC_URI is currently the only metadata for which
I can think of a possible application.

> The idea sounds like most ideas; extremely powerful and extremely
> dangerous.

I completely agree: Such a thing could be easily misused.
But directly modifying the ebuild or doing something strange
in /etc/portage/bashrc can be misused as well.
Finally, it is always the user who is responsible for what he is doing.
The only really "safe" alternative is to give the user no choice at all -
but even then he will probably find a hack around.

> It would possibly make debugging a bitch though; I am unsure how we could
> make the changes visible so that it would be obvious during debugging.

At least, there would be an "official" file in a documented format which
describes the changes. For the alternative - if the user just "bumps"
the ebuild and does some modifications - it is much less clear what he
has done. This is the situation anyway:
There is no reliable automatic way to tell whether a problem somebody
reports with some package is actually caused by the user's modification of
another ebuild.  You have to trust the user in this respect...

such a modification
of another package - you have to trust the user in this respect...
Comment 10 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2008-02-12 01:46:20 UTC
(In reply to comment #6)
> For installation of package A some package B is needed which has a huge
> dependency tree, none of which you do want, but without these dependencies B
> will work only very rudimentary (but sufficiently for package A). Of course,
> you cannot seriously suggest the maintainer of package B to provide
> an "install-me-almost-not-working" useflag.

Package B could have "minimal" or "+something" or "nosomething" USE flag.
Comment 11 Martin Väth 2008-02-12 15:41:12 UTC
(In reply to comment #10)
> (In reply to comment #6)
> > Of course,
> > you cannot seriously suggest the maintainer of package B to provide
> > an "install-me-almost-not-working" useflag.
>
> Package B could have "minimal" or "+something" or "nosomething" USE flag.

With a useflag inflation this might be solved in theory.
In practice, maintainers will refuse such requests, and I can understand this
to some extent: Almost nobody is willing to test such cases, and it can lead
to very subtle bugs. Moreover, these special cases are often useful only
for very particular setups which does not justify to introduce a useflag for
the whole gentoo community.

Maybe I should give some more examples:
  1. The original purpose of rpppoek is to be a front-end of rp-pppoe; so
this dependency is unconditional. However, actually rpppoek can be tweaked
(by putting some script in your path) to call /etc/init.d/net.ppp0 start/stop
via sudo instead. I use such a script, and so for *me*, the dependency on
rp-pppoe is superfluous. But introduce a useflag just for perhaps one person?
  2. Over time, kde-3 pulled in more and more serious dependencies (most
prominent examples are htdig and avahi/mDNSResponder). The reason is that
there were some bug reports proofing that certain problems could arise without
this dependencies. Obviously, the maintainers decided to make the dependencies
unconditional to avoid all such reports. I can understand this from the
maintainer's point of view, but IMHO it is also valid to build the system
without these extensions and live with the consequences (of course, this
implies that the user should be responsible enough to not file a bug which
might be related to this change before testing it with a "supported"
combination).
Comment 12 Jakub Moc (RETIRED) gentoo-dev 2008-02-12 21:07:46 UTC
(In reply to comment #11)
> (of course, this implies that the user should be responsible enough to not file > a bug which might be related to this change before testing it with a "supported"
> combination).

Of course, the above will never ever happen and I'm gonna be flooded with nonsensical bugs about 'missing' dependencies. Sorry to repeat myself, but we have overlays, use them. There's no legitimate reason for your request.
Comment 13 Martin Väth 2008-02-13 09:09:42 UTC
(In reply to comment #12)
> 
> Of course, the above will never ever happen and I'm gonna be flooded with
> nonsensical bugs about 'missing' dependencies.

I can understand that you dislike this idea. It is always the case if somebody
has more administration tools he has more possibilities to break the system.
But should this be a reason to hide the toolbox also from a responsible
user? (This is what I hate most on MS systems).
  Somebody who behaves irresponsible can do the same already now by patching
the ebuild. Actually, I do not believe that the number of "irresponsible"
reports would increase, because if somebody wants to avoid a dependency
seriously enough that he tracks down the ebuild pulling it in, he will patch
it now anyway (or use a dummy package or misuse package.provided or whatever -
the latter is even worse since the user would not even realize *which*
packages do need the dependencies) - and only the step of actually patching
the ebuild would be more convenient with the new feature.
Comment 14 Jakub Moc (RETIRED) gentoo-dev 2008-02-17 20:09:50 UTC
I think we should focus on critical missing features in portage such as use-based deps and things like this should be immediately closed as WONTFIX/INVALID - end of story. Pure waste of time.
Comment 15 Alec Warner (RETIRED) archtester gentoo-dev Security 2008-02-18 07:46:44 UTC
(In reply to comment #14)
> I think we should focus on critical missing features in portage such as
> use-based deps and things like this should be immediately closed as
> WONTFIX/INVALID - end of story. Pure waste of time.
> 

Dude we got your opinion already, we don't need to see it again.
Comment 16 avx 2011-08-14 11:31:51 UTC
Yeah, old bug, but imho still more than valid.

The count of people being annoyed because of a lacking Feature like this is on the rise, in part because some devs seem to prefer the easy way out. IMHO, this runs contrary to Gentoo's premiss of flexibility through choice.

No one, at least on this bug, requests support in the case someone brought havoc on themselves, still there seems to be a steady trend calling - well, not directly - people dumb and withholding tools to achieve their goals.

There may be better ways to achieve what @Martin Väth others like me ask for, but totally ignoring the problem is imho no solution, for ignoring, there's always $buntu.
Comment 17 Zac Medico gentoo-dev 2011-08-14 18:48:50 UTC
Another possible solution might be to provide a way to create an ebuild in an overlay that inherits an ebuild from another repo. Then you'd be able to add/remove dependencies, and a lot more more, while duplicating as little as possible.
Comment 18 Martin Väth 2011-08-15 10:55:14 UTC
(In reply to comment #17)
> Another possible solution might be to provide a way to create an
> ebuild in an overlay that inherits an ebuild from another repo.

This sounds useful but still has the disadvantage that the
ebuild must match the version number so that e.g. for
upgrades you must manually (or by some script) observe that
an upgrade of the ebuild in the overlay is necessary.
(Of course, I am aware that one should be careful with upgrades
anyway, but the default "apply the same as before" is more likely).

Moreover, there is no way to replace e.g. globally a dependency on
foo/bar to a dependency on foo/not-in-the-tree-fork-of-bar
(unless, by accident, there is a virtual for foo/bar).
If you want to do such a thing you practically have to maintain
a whole tree by yourself (or cheat by using package.provided or
installing a dummy foo/bar which is both a bad hack).

Since my first post I had quite some time to think about the
issue and arrived at another suggestion:

By current means (/etc/portage/env, /etc/portage/bashrc, and
/etc/portage/package.env) it is currently possible to "patch" almost
all aspects of ebuilds (particular ebuilds or certain classes of
ebuilds) with two exceptions:
It is not possible to add some "inherit" or to change the "metadata"
variables. I understand that the reason for the latter is that the
metadata is stored in an independent database, but how about adding
support for something like /etc/portage/package.metadata which could
act like /etc/portage/package.env when accessing the metadata
database?
For instance, this file/dir could lists package together with
corresponding [python or even better bash] scripts which get the
original metadata as environment variables and which are allowed to
modify these. I suppose that if this file is used at the interface
to the database backend of portage, neither the effort to implement
this nor the slowdown of portage if the feature is unused would be
very high.