Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
jeroen@misha /keeps/gentoo/cvs/gentoo-x86/kde-base/libkmahjongg $ cvs update && eshowkw && cd ../kmahjongg/ && cvs update && eshowkw cvs update: warning: `libkmahjongg-4.0.1.ebuild' was lost U libkmahjongg-4.0.1.ebuild Keywords in /keeps/gentoo/cvs/gentoo-x86 for kde-base/libkmahjongg : | a a a h i m m p p s s s s x x | l m r p a 6 i p p 3 h p p 8 8 | p d m p 6 8 p c c 9 a a 6 6 | h 6 a 4 k s 6 0 r r - | a 4 4 c c f | - b | f s | b d | s | d ------+------------------------------ 4.0.1 | ~ ~ Keywords in /keeps/gentoo/cvs/gentoo-x86 for kde-base/kmahjongg : | a a a h i m m p p s s s s x x | l m r p a 6 i p p 3 h p p 8 8 | p d m p 6 8 p c c 9 a a 6 6 | h 6 a 4 k s 6 0 r r - | a 4 4 c c f | - b | f s | b d | s | d ------+------------------------------ 3.5.8 | + + + + + + + + ~ 3.5.9 | ~ ~ ~ ~ ~ ~ ~ ~ ~ 4.0.1 | ~ ~ ~ jeroen@misha /keeps/gentoo/cvs/gentoo-x86/kde-base/kmahjongg $ repoman full Setting paths: PORTDIR = "/keeps/gentoo/cvs/gentoo-x86" PORTDIR_OVERLAY = "" RepoMan scours the neighborhood... RepoMan sez: "If everyone were like you, I'd be out of business!" jeroen@misha /keeps/gentoo/cvs/gentoo-x86/kde-base/kmahjongg $ grep libkmah kmahjongg-* kmahjongg-4.0.1.ebuild: >=kde-base/libkmahjongg-${PV}:${SLOT}" kmahjongg-4.0.1.ebuild:KMEXTRACTONLY="libkdegames libkmahjongg" jeroen@misha /keeps/gentoo/cvs/gentoo-x86/kde-base/kmahjongg $ grep kmah ../../profiles/package.mask =kde-base/kmahjongg-4* =kde-base/libkmahjongg-4* jeroen@misha /keeps/gentoo/cvs/gentoo-x86/kde-base/kmahjongg $
If they're package.masked, they're not visible, so of course they don't get checked for visibility...
[continued] jeroen@misha /keeps/gentoo/cvs/gentoo-x86/kde-base/kmahjongg $ rm ../../profiles/package.mask jeroen@misha /keeps/gentoo/cvs/gentoo-x86/kde-base/kmahjongg $ repofull Repoman is unable to determine PORTDIR or PORTDIR_OVERLAY from the current working directory. jeroen@misha /keeps/gentoo/cvs/gentoo-x86/kde-base/kmahjongg $ touch ../../profiles/package.mask jeroen@misha /keeps/gentoo/cvs/gentoo-x86/kde-base/kmahjongg $ repoman full Setting paths: PORTDIR = "/keeps/gentoo/cvs/gentoo-x86" PORTDIR_OVERLAY = "" RepoMan scours the neighborhood... DEPEND.bad 2 kde-base/kmahjongg/kmahjongg-4.0.1.ebuild: ~hppa(default-linux/hppa/2006.1) ['>=kde-base/libkmahjongg-4.0.1:kde-4'] kde-base/kmahjongg/kmahjongg-4.0.1.ebuild: ~hppa(default-linux/hppa/2007.0) ['>=kde-base/libkmahjongg-4.0.1:kde-4'] DEPEND.badindev 2 kde-base/kmahjongg/kmahjongg-4.0.1.ebuild: ~hppa(default-linux/hppa/2007.0/desktop) ['>=kde-base/libkmahjongg-4.0.1:kde-4'] kde-base/kmahjongg/kmahjongg-4.0.1.ebuild: ~hppa(default-linux/hppa/2007.0/server) ['>=kde-base/libkmahjongg-4.0.1:kde-4'] RDEPEND.bad 2 kde-base/kmahjongg/kmahjongg-4.0.1.ebuild: ~hppa(default-linux/hppa/2006.1) ['>=kde-base/libkmahjongg-4.0.1:kde-4'] kde-base/kmahjongg/kmahjongg-4.0.1.ebuild: ~hppa(default-linux/hppa/2007.0) ['>=kde-base/libkmahjongg-4.0.1:kde-4'] RDEPEND.badindev 2 kde-base/kmahjongg/kmahjongg-4.0.1.ebuild: ~hppa(default-linux/hppa/2007.0/desktop) ['>=kde-base/libkmahjongg-4.0.1:kde-4'] kde-base/kmahjongg/kmahjongg-4.0.1.ebuild: ~hppa(default-linux/hppa/2007.0/server) ['>=kde-base/libkmahjongg-4.0.1:kde-4'] Please fix these important QA issues first. RepoMan sez: "Make your QA payment on time and you'll never see the likes of me." jeroen@misha /keeps/gentoo/cvs/gentoo-x86/kde-base/kmahjongg $
Note: repofull is an alias to "repoman full". I tried to rewrite all the local quirks into generic terms and forgot that one.
(In reply to comment #1) > If they're package.masked, they're not visible, so of course they don't get > checked for visibility... That's fine for a package manager, but not for a development tool.
(In reply to comment #4) > (In reply to comment #1) > > If they're package.masked, they're not visible, so of course they don't get > > checked for visibility... > > That's fine for a package manager, but not for a development tool. But there's no sane way for a development tool to do it either. It doesn't know whether something's in package.mask because it's broken, because it's insecure, because it's deprecated, because it's dead, because it needs more testing, because it's about to be removed, because it has broken deps and is being phased out or some other reason.
(In reply to comment #4) > That's fine for a package manager, but not for a development tool. Great; so, with your suggestion, lets make everyone totally ignore repoman because it will render p.mask totally useless and spit out tons of totally irrelevant junk that noone's intereted in and that harms noone. Way to go for sure...
Marking INVALID as this suggestion makes exactly zero sense. Feel free to devrel me as needed.
I think it's a bug. If not then it's a missing feature. If I can only figure out dependency problems by temporarily replacing package.mask with an empty file, then perhaps repoman could do it by optionally ignoring package.mask.
The whole point of package.mask is making the packages invisible from there checks and from users... If you failed to notice that so far, then perhaps your recruiter failed completely. If you want it changed, then kinda take this to mailing list and out of bugzilla - since it's been that way for ages.
(In reply to comment #9) > The whole point of package.mask is making the packages invisible from there > checks and from users... If you failed to notice that so far, then perhaps > your recruiter failed completely. > > If you want it changed, then kinda take this to mailing list and out of > bugzilla - since it's been that way for ages. Why do you keep closing this bug?
(In reply to comment #10) > Why do you keep closing this bug? In order to keep useless noise out of our bug tracker. As said, feel free to devrel me, meanwhile most people would assume that developers would have had at least a minimal clue about portage working before filing 'bugs'.
It's a valid feature request...
(In reply to comment #12) > It's a valid feature request... Feature requests making repoman totally unusable for developers are not valid at all. Next time I'd suggest that you use your brain before keywording metabuilds (such as qt-4.4) without keywording their dependencies - it will be a whole lot more productive than blaming repoman and portage for your brainfart.
I imagine that we could do something as simple as add a new command line option that causes repoman to warn about missing dependencies for masked packages.
(In reply to comment #14) > I imagine that we could do something as simple as add a new command line option > that causes repoman to warn about missing dependencies for masked packages. You could, and the output would be worse than worthless, because people might mistakenly think that the output isn't worthless.
So how exactly is this output worthless? I ran across this exact problem the other day, as I've masked a few packages that are used for releases, but that should never really be used on a live Gentoo install. While making modifications to these packages in the Gentoo repository, I noticed no dependency problems, but when I ran the same checks on my snapshot repository (without the offending package.mask entries), repoman informed me of my error, which I promptly fixed. Not everything is masked for a a bad reason. Sometimes things are masked for testing. Allowing the developers working on those packages to actually get the feedback that they need to do their testing and development sounds like a good idea to me. After all, Jeroen did ask for it to be optional. Those that want it, get it. Those that don't, don't. Everybody wins!
(In reply to comment #16) > So how exactly is this output worthless? The output would tell the developer what would happen if package.mask were emptied, a scenario which will never happen. What the developer actually wants to know is what would happen if a small subset of package.mask were not present, and from a UI perspective the easiest way to get that is for the developer to temporarily comment out just the relevant parts themselves.
I think what repoman should do at least is to notify the user when certain checks are skipped.
We want an option to make repoman behave, essentially, as if package.mask does not exist. So, would --without-mask be a good name for the option?
(In reply to comment #19) > We want an option to make repoman behave, essentially, as if package.mask does > not exist. So, would --without-mask be a good name for the option? That would be lovely. Option or no, I like Marius' comment #18 a lot, too: repoman should notify which checks it ommits (and for what reason) - if that wouldn't make the output so verbose as to be ignored by its users, that is.
Another good reason to get this in quickly, it seems: jeroen@misha /keeps/gentoo/cvs/gentoo-x86/profiles $ cvs diff -r 1.8466 package.mask Index: package.mask =================================================================== RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v retrieving revision 1.8466 retrieving revision 1.8467 diff -u -B -r1.8466 -r1.8467 --- package.mask 4 Apr 2008 02:56:19 -0000 1.8466 +++ package.mask 4 Apr 2008 05:26:16 -0000 1.8467 @@ -1,5 +1,5 @@ #################################################################### -# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.8466 2008/04/04 02:56:19 robbat2 Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.8467 2008/04/04 05:26:16 philantrop Exp $ # # When you add an entry to the top of this file, add your name, the date, and # an explanation of why something is getting masked @@ -533,7 +533,9 @@ =dev-java/freemarker-2.3.11 # Ingmar Vanhassel <ingmar@gentoo.org> (16 Jan 2008) -# Mask KDE 4.0.0 for testing. This release of KDE 4 will not be unmasked. +# Mask KDE 4.0.x for testing. This release of KDE 4 will not be unmasked. +# This is still not intended for mainstream so DO NOT KEYWORD IT without +# talking to the KDE herd first. # KDE 4 guide: http://www.gentoo.org/proj/en/desktop/kde/kde4.xml =kde-base/amor-4* =kde-base/ark-4* If people are this anxious that their package.masked stuff is touched, then obviously repoman SHOULD warn against committing changes. Especially as it is policy: "If you didn't mask the ebuild, always contact the developer listed in the package.mask comments prior to taking any action."[1] [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1
Uh... Just who would be keywording things whilst they're still in package.mask? Are you suggesting that developers are that careless?
(In reply to comment #22) > Uh... Just who would be keywording things whilst they're still in package.mask? I said "touching". I didn't say "keywording". philantrop did. I merely quoted him. > Are you suggesting that developers are that careless? Yes.
Then the solution is to provide a clear way for developers to see the mask status of a package, which is an entirely different issue than this bug.
(In reply to comment #24) > Then the solution is to provide a clear way for developers to see the mask > status of a package, which is an entirely different issue than this bug. I didn't suggest the check/warning of comment #18. Nobody raised any objection to the injection of said suggestion into this bug report. My new suggestion merely takes it further to where it ought to be: repoman should warn against committing changes to masked ebuilds. Maybe that warrants a new bug...
(In reply to comment #23) > > Are you suggesting that developers are that careless? > Yes. We've only had that problem once so I don't think it's that urgent. I only added that part to the mask to be sure people don't have to read and understand policy as was pretty much the turnout of a recent discussion.
This is fixed in 2.1.5_rc1.
