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