stuff like: dependency.unknown 2 dev-ml/lwt/lwt-2.3.0.ebuild: RDEPEND: !<www-servers/ocsigen-1.1 dev-ml/lwt/lwt-2.3.1.ebuild: RDEPEND: !<www-servers/ocsigen-1.1 are useful to ensure a sane upgrade path from old systems, even if the offending version has been removed.
This behavior was requested in bug 381087. It's just a warning, to indicate that there are no matching ebuilds in the tree. In cases like this, it's quite possible that the version is specified incorrecttly, and the warning is arguably justified by the fact that repoman cannot verify the validity of the version.
(In reply to comment #1) > This behavior was requested in bug 381087. It's just a warning, to indicate > that there are no matching ebuilds in the tree. In cases like this, it's quite > possible that the version is specified incorrecttly, and the warning is > arguably justified by the fact that repoman cannot verify the validity of the > version. you can check CVS history but I seriously doubt its desirable a warning like this makes people removing the blockers which hurts QA rather than improving it
(In reply to comment #2) > you can check CVS history but I seriously doubt its desirable For one thing, that wouldn't work for blockers against things in overlays. > a warning like this makes people removing the blockers which hurts QA rather > than improving it This seems like like a training issue. We can train people to do otherwise, and perhaps modify the repoman output to clarify the issues involved.
We could add a way to whitelist certain atoms so they're ignored by the dependency.unknown check, sort of like a spelling dictionary.
(In reply to comment #4) > We could add a way to whitelist certain atoms so they're ignored by the > dependency.unknown check, sort of like a spelling dictionary. hmm, you may want to check the tree for stats: how many useful blockers trigger dependency.unknown vs how many mispelled ones ? a whitelist will duplicate the information for the benefit of very few cases; what _could_ be useful instead, if the point is to avoid typos, could be something like checking if there's a package with a very close name (using a well chosen metric on package names) and output the warning only in that case, with a whitelist mechanism for the case the metric heuristic is not enough. a lot of packages trigger this false-positive warning; i just ignore it, but then in the flood of useless warnings, i may miss a useful one...
Okay some words on this. I did file this bug while I was writing a little script which should make stable/keyword requests easier for developers. The tool checks for every arch and it's profiles if there are dependencies and deep dependencies of a package in question which need to be keyworded/stabled in advance. While testing it I got errors about missing packages. I noticed this are all blockers which have been removed some time ago. For my script I simply ignored the blockers because they do not matter for keyword/stable requests. So I thought it would be a good idea if repoman prints a warning if a dependency does not exist. When looking at repomans code I recognized it already does this but it excluded blockers. I thought it would be good idea to include them because they should not stay in the dependencies forever and thus opened bug #381087. Personally I don't mind if this check is reset to the old state. However I think it is good to get reminded about the dependencies so they can be removed some time. Also the other cases like typos are probably worth to keep the check. Maybe the repoman checks can be categorized in critical and informational. Informational checks are only executed when repoman is called with a flag like -dev to include developer profiles. This way it does not clutter he output by default but the checks can be executed when the flag is active. Also you don't have to maintain a whitelist that allows skipping the check for certain atoms. Another probably a simpler approach would be to print certain output only in verbose mode.
(In reply to comment #2) > a warning like this makes people removing the blockers which hurts QA rather > than improving it Yeah, I think this is a pretty good reason to disable this check for blockers. For example, I've just noticed a necessary blocker removed from udev: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-182.ebuild?view=log#rev1.7
(In reply to comment #6) > Maybe the repoman checks can be categorized in critical and > informational. Informational checks are only executed when repoman is called > with a flag like -dev to include developer profiles. That would be nice. For now I've disabled the check for blockers: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=67b8da916f1b4a601d09c3f867c005b39a04f28e
This is fixed in 2.1.10.51 and 2.2.0_alpha95.
I think training is the more appropriate solution for this bug, because now with it disabled, it is possible to have typos in blockers either by specifying an invalid version or a completely invalid package name.
