| Summary: | Add a repoman check for dropped keywords | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Jeroen Roovers (RETIRED) <jer> |
| Component: | Repoman | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | philantrop, qa, wolf31o2 |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://devmanual.gentoo.org/keywording/index.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 216231 | ||
|
Description
Jeroen Roovers (RETIRED)
2008-02-09 06:17:55 UTC
How would you go about implenting this? -Alec Check it against previous ebuilds, even ones which are about to be deleted. If there's no previous ebuild, check passes. Also, it is technically incorrect to ever drop KEYWORDS. Yes, ever. Instead, you should -arch the ones that aren't supported, so the KEYWORDS are technically never dropped. It also keeps problems from creeping up, such as the one below, that I bet is quite common. foo-1.0 supports amd64 and sparc foo-1.1_beta supports only amd64 foo-1.1 supports amd64 and sparc (Assuming there's no ~arch, so pretend we only have one keyword) The developer commits foo-1.1_beta with KEYWORDS="amd64" only. He then goes to do foo-1.1 a couple months later and copies his foo-1.1_beta ebuild, thereby accidentally dropping the sparc KEYWORDS from the ebuild. I would bet that this is a very common scenario of how KEYWORDS get dropped. (In reply to comment #2) > Also, it is technically incorrect to ever drop KEYWORDS. Yes, ever. Let's say I bump from foo-1.0 to foo-2.0. foo-1.0 worked on arm and thus was marked ~arm. foo-2.0 was completely re-written and switched to a new build system. What do I do about 2.0 on arm? ~arm? I have no arm device and thus can't test. -arm? Means it *cannot* work on arm (because it was tested and failed). If I keep ~arm, I let users update from 1.0 to 2.0 and in the worst case, they might find out the hard way that foo-2.0 doesn't work at all on arm. That's completely inacceptable. Now let's assume that foo is a bootloader... Ouch. The only sensible decision is to drop arm's keyword and notify the arm arch team. Dropping keywords can be perfectly fine. Here we have the case of an arch team member keywording randomly and without a clue about the stuff he keywords. Like keywording KDE4 stuff without kdelibs and kdepimlibs which are the base for basically *any* KDE4 application. Said dev obviously didn't even bother to install (not to speak of testing) the stuff he keyworded or he would have seen that he didn't keyword properly. (In reply to comment #3) > If I keep ~arm, I let users update from 1.0 to 2.0 and in the worst case, they > might find out the hard way that foo-2.0 doesn't work at all on arm. That's > completely inacceptable. > The only sensible decision is to drop arm's keyword and notify the arm arch > team. If you feel you have to, you package.mask it and ask the arch team to test it. > Dropping keywords can be perfectly fine. Here we have the case of an arch team > member keywording randomly and without a clue about the stuff he keywords. Like > keywording KDE4 stuff without kdelibs and kdepimlibs which are the base for > basically *any* KDE4 application. Said dev obviously didn't even bother to > install (not to speak of testing) the stuff he keyworded or he would have seen > that he didn't keyword properly. My name is Jeroen Roovers. Why the smear campagne? Can't you move that to a proper devrel bug asking to remove my CVS commit rights? (In reply to comment #4) > If you feel you have to, you package.mask it and ask the arch team to test it. Just because *one* arch might have a problem? Doesn't seem a good solution. If most arches could run into problems, yes, but not if it's just one. > My name is Jeroen Roovers. Why the smear campagne? Can't you move that to a > proper devrel bug asking to remove my CVS commit rights? I'm not here to annoy you or anything. I just think you're wrong and I'm trying to explain why. (In reply to comment #5) > (In reply to comment #4) > > If you feel you have to, you package.mask it and ask the arch team to test it. > > Just because *one* arch might have a problem? Doesn't seem a good solution. If > most arches could run into problems, yes, but not if it's just one. We have per-arch package.mask (in profiles/...) maybe Jer was talking about that. > > > My name is Jeroen Roovers. Why the smear campagne? Can't you move that to a > > proper devrel bug asking to remove my CVS commit rights? > > I'm not here to annoy you or anything. I just think you're wrong and I'm trying > to explain why. > My name is Alec Warner, hi :) OK, let's redo this one. I am now less focused on the ad hominems... (In reply to comment #3) > (In reply to comment #2) > > Also, it is technically incorrect to ever drop KEYWORDS. Yes, ever. > > Let's say I bump from foo-1.0 to foo-2.0. foo-1.0 worked on arm and thus was > marked ~arm. foo-2.0 was completely re-written and switched to a new build > system. Completely rewritten is something that almost never happens. Most packages are written to be portable, i.e. they do not make architecture specific assumptions and if they do, the developers make sure that the arch specific stuff is applied only to a specific arch. Whenever a package uses specific code for specific architectures (like threading, SIMD stuff and so on) even a "major" or "complete rewrite" would almost never touch the arch specific code - it's bound to the hardware and therefore doesn't change. > What do I do about 2.0 on arm? > > ~arm? I have no arm device and thus can't test. Version 1 worked and you have no evidence that 2 doesn't work on arm. You mark it ~arm. > -arm? Means it *cannot* work on arm (because it was tested and failed). Er, so it's entirely irrelevant. > If I keep ~arm, I let users update from 1.0 to 2.0 and in the worst case, they > might find out the hard way that foo-2.0 doesn't work at all on arm. That's > completely inacceptable. It's their choice to run ACCEPT_KEYWORDS=~arm and their responsibility. If it's a major rewrite all the non-arch specific code has been touched and you should package.mask it for extensive testing. You're basically saying that if you test it on an arch you have access to, it's suddenly OK to add the ~keyword for that arch back. How do I or any user know on how many different systems you have tested it? > Now let's assume that foo is a bootloader... Ouch. FUD. Bootloaders on "alternative" arches are arch specific. I.e. you wouldn't normally have anything to do with them anyway unless you were a member of a specific arch team. > The only sensible decision is to drop arm's keyword and notify the arm arch > team. OK, then in the light of the recent KDE 4 bump, why weren't arch teams notified? Besides, you haven't argued why dropping keywords is the best solution - you have merely > Dropping keywords can be perfectly fine. OK, let's use your KDE 4 example instead. My point in rekeywording was, that I was visiting all those package directories anyway so I might as well save myself rekeywording ~300 ebuilds while I was keywording the split KDE packages for HPPA. Policy forbids dropping keywords without notification of the arch teams and yet your team did it. The single reason I did find (after the package.mask ignorance in repoman of bug #212509) that grants KDE team the right to drop keywords is that some split packages had been split further. While this is a valid reason to drop keywords, HPPA team was never approached about this. If proper procedure had been followed, I would probably have granted you permission to keyword the newly split packages as ~hppa yourselves. Meaning, a kfumble-4 version bump and its new dependency libkfumble-4 could both have been keyworded ~hppa from the start, instead of dropping the kfumble-4 keyword and then asking HPPA team to readd them. (In reply to comment #7) > > ~arm? I have no arm device and thus can't test. > Version 1 worked and you have no evidence that 2 doesn't work on arm. You mark > it ~arm. No. If the thing has seen major changes I will *not* ~arm it. ~arch is not a playground but the next "stable candidate" as our QA put it. > > If I keep ~arm, I let users update from 1.0 to 2.0 and in the worst case, they > > might find out the hard way that foo-2.0 doesn't work at all on arm. That's > > completely inacceptable. > It's their choice to run ACCEPT_KEYWORDS=~arm and their responsibility. No, it's *our* responsibility *not* to break users' systems. > a major rewrite all the non-arch specific code has been touched and you should > package.mask it for extensive testing. And that's exactly what we did for KDE 4.0.x. > You're basically saying that if you test > it on an arch you have access to, it's suddenly OK to add the ~keyword for > that arch back. > How do I or any user know on how many different systems you have > tested it? You don't have to. If I keyword a package under my maintainership ~arch I've tested it and am sufficiently sure it won't break on the respective arch. > OK, then in the light of the recent KDE 4 bump, why weren't arch teams > notified? Because it's broken crap that shouldn't be re-keyworded yet. > Policy forbids dropping keywords without notification of the arch teams > and yet your team did it. The single reason I did find (after the package.mask > ignorance in repoman of bug #212509) that grants KDE team the right to drop > keywords is that some split packages had been split further. To drop the keywords for completely re-written stuff which switched to a new build system was the only responsible decision. No other arch teams have complained about that. > While this is a valid reason to drop keywords, HPPA team was never approached > about this. If proper procedure had been followed, I would probably have > granted you permission to keyword the newly split packages as ~hppa > yourselves. We wouldn't have done that anyway because we feel responsible for our users. We don't just keyword stuff ~arch because we *suspect* it might work. This is not what we consider responsible package maintenance and far from any QA. cc'ing QA. (In reply to comment #8) > cc'ing QA. I suppose that is because you want the following to be clarified or changed in devmanual (a QA subproject): ------------------ === Keywording on Upgrades === When upgrading, drop all existing keywords from arch to ~arch, and leave any existing ~arch keywords intact. This must be done even if you think you're just making a trivial fix — there have been several examples of the stable tree getting broken this way. Sometimes you may need to remove a keyword because of new unresolved dependencies. __If you do this, you must file a bug notifying the relevant arch teams.__ This also applies to revision bumps, not just to upstream version changes. ------------------ __emphasis__ added. The emphasised bit explains exactly why I think this repoman check should be added. If you drop the KEYWORDS for my architecture, I'd be pissed. What I would *expect* instead is that if you're uncomfortable with a package being marked ~arch on my architecture, that you LEAVE ~arch ALONE in the ebuilds and use my architecture's package.mask file to mask the packages. The absolute last thing that you should ever do is drop my architecture from the ebuild, entirely. After all, you *do* want people to test your packages on my architecture, right? Dropping the KEYWORDS from an ebuild is a piss-poor idea, for pretty much any line of reasoning. If something isn't a candidate for stable, it should be in package.mask, rather than simply missing KEYWORDS. Again, this is *exactly* why KEYWORDS end up getting dropped between versions. This is fixed in 2.1.5_rc1. |
