I am personally really tired of needing to fix lots of ebuilds (some of them even recently committed) that are not specifying any slot for deps like libpng, openssl... I think this warning should be fatal for not needing to "fix the mess" later when people start to report bugs and so
I'm opposed to making warnings fatal while there are still "broken" ebuilds in the tree. If I am making an unrelated change to a package, I should not need to run repoman --force to commit it. -1 from me.
Isn't there a way to make repoman behave differently when a new ebuild is added? Otherwise this is always a chicken egg problem, we have more than 1000 ebuilds with this issue and it seems people are simply ignoring the issue. Are we going to keep this situation forever?
Making it fatal only for "new" ebuilds would be fine.
Yes, the ChangesBase class for all vcs plugin modules has: self.new_ebuilds = set() and when a scan is done it adds any new ebuilds being added to that variable. Pacho, the best way to get this added to repoman is to create some genb0rk repo pkgs that can test all possible conditions of the check. This would include ebuilds that are not in the normal category/pkg dir that can be added manually for testing. Please place the 2 test ebuilds to be added (both conditions pass/fail) in a metadata/tests/${CAT}/${PKG}.
How can it distinguish new ebuilds from revbumps needed to fix a major problem?
It can't at this time detect the difference between a new version and a revision bump. But a revision bump is a new ebuild. If the ebuild is being fixed which causes a revision bump, then shouldn't this error also be fixed? If not, I think it should possible to exclude a new ebuild if it has a revision other than -r0 at least for the git vcs.
What I'm really concerned about (and I think that was discussed by the Council as well, on some relevant topic) is that this kind of behavior makes it hard to do urgent non-maintainer fixes without putting the whole burden upon the person doing the fix. And this might even get as far as to security bumps. However, maybe it'd be enough to have another repoman option, like --assume-no-new-ebuilds
I agree with Michał that it's problematic for things like urgent security fixes. However, I'm not sure I agree that this is problematic enough to warrant a new option, or any other work, really. In short, I agree with Mike's first comment.
(In reply to Brian Dolbec from comment #4) > Yes, the ChangesBase class for all vcs plugin modules has: > > self.new_ebuilds = set() > > and when a scan is done it adds any new ebuilds being added to that variable. > > > Pacho, the best way to get this added to repoman is to create some genb0rk > repo pkgs that can test all possible conditions of the check. This would > include ebuilds that are not in the normal category/pkg dir that can be > added manually for testing. > > Please place the 2 test ebuilds to be added (both conditions pass/fail) in a > metadata/tests/${CAT}/${PKG}. Sorry but I don't follow what do you want me to do :/ What tests are you referring to? (I am not familiar with repoman apart of a user)
(In reply to Pacho Ramos from comment #9) > (In reply to Brian Dolbec from comment #4) > > Yes, the ChangesBase class for all vcs plugin modules has: > > > > self.new_ebuilds = set() > > > > and when a scan is done it adds any new ebuilds being added to that variable. > > > > > > Pacho, the best way to get this added to repoman is to create some genb0rk > > repo pkgs that can test all possible conditions of the check. This would > > include ebuilds that are not in the normal category/pkg dir that can be > > added manually for testing. > > > > Please place the 2 test ebuilds to be added (both conditions pass/fail) in a > > metadata/tests/${CAT}/${PKG}. > > Sorry but I don't follow what do you want me to do :/ What tests are you > referring to? (I am not familiar with repoman apart of a user) the genb0rk repo [1] is a pkg tree specifically for testing repoman. If you want repoman to get this change. Then please make a few test case ebuilds that I can use to test the changes I will have to make to ensure it is correct. eg: category = slot-deps packages = correct/unspecified/... Make some minimal test ebuilds for those pkgs. Then create as many test ebuilds to add to those pkgs to test your new ebuilds being added that triggers the fatal as well as non-fatal warnings in matching category/pkg directories under the metadata directory. I can then use those test ebuilds to test all aspects of the code changes. Have a look at the existing test case ebuilds, there are also skeletons [2] you can use, just edit the descriptions to reflect the test/error. Also note, that this repo will be used for doing testing for the stage3 re-write of repoman. The more coverage it has for the different things that repoman checks, the less bugs are likely to be introduced in those releases. [1] https://gitweb.gentoo.org/repo/proj/gen-b0rk.git/ [2] https://gitweb.gentoo.org/repo/proj/gen-b0rk.git/tree/
repoman support has been removed per bug 835013. Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
