Created attachment 315765 [details, diff] mask VCS ebuilds patch If this patch looks good, I can commit it (or you can, git am). Just trying to resolve a situation in #gentoo-dev because it "wasn't documented"
This somewhat overlaps with <http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html> where a more complete list of reasons is given.
(*Mubles something about people who think that just because it's not written as they did it it's allowed*) Jeremy, Ulrich, could you please just update that cvs-sources part to be scm-sources? I don't think I have the time tonight, but it seems like it's the best thing to merge the two.
Well, yea. I am amicable to that change, but the cvs-sources page goes in to talk specifically about cvs.eclass. This, IMO, precludes a a simple "fix" to that page to make it apply to "VCS/SCM"
Unless, you just change the header and first two sections. (and maybe the title of the page)
Lets see if we can finally merge this one
I'd like to see it more explicitly mention that live ebuilds should never have keywords (and therefore don't need to be p.masked). And that packaging snapshots is preferred over vcs-tag ebuilds.
I am sure this is documented somewhere as we ask that during the recruitment sessions. I ll have a look
Created attachment 362444 [details, diff] 0002-src_unpack-cvs-sources-delete-reference-to-package.m.patch This patch could also go in along with the first one. It removes the reference to package.mask from the section about cvs sources since the masking policy is covered in the first patch.
I still need to see a QA ack or nack on these patches.
The concerns from comment #1 and comment #2 haven't been addressed still. Maybe the easiest solution would be to remove the list of reasons from darkside's patch and add a reference to the "CVS sources" section instead.
QA acks the first patch, second one should also fix svn-sources (I think I submitted a pull request for this just a bit ago without realizing this bug exists, actually...)
(In reply to Chris Reffett from comment #11) > QA acks the first patch, second one should also fix svn-sources (I think I > submitted a pull request for this just a bit ago without realizing this bug > exists, actually...) Can we have a pull request with the first patch please? :)
I merged the pull request for the second patch http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commit;h=5c63d7ec207f1658f75ab82a86d22f69657b8feb
Oh, if you plan to unmask the masked live ebuilds, please make sure you give a heads-up in the list so people will not accidentally start pulling live ebuilds in case they have weird entries in package.keywords.
(In reply to Markos Chandras from comment #13) > I merged the pull request for the second patch > > http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commit; > h=5c63d7ec207f1658f75ab82a86d22f69657b8feb Sorry, but where was this discussed? Jeremy's patch had "VCS Ebuilds should always be masked or without keywords" which documents current practice, whereas now the documentation has been changed to say that only KEYWORDS="" is allowed. Please also that this also forecloses a pending council decision: http://www.gentoo.org/proj/en/council/meeting-logs/20131119-summary.txt (last topic, "Open floor")
(In reply to Ulrich Müller from comment #15) > Sorry, but where was this discussed? In random places on IRC (including gentoo-council, gentoo-dev) multiple times; every time everyone agrees, nobody appears to disagree. But nobody is acting on it in any way; there's been two times it could have been discussed in Council, but apparently it's a too small matter to be discussed there. Kudos to creffett for actually doing something about it. Well, now that you have a patch here you could discuss it again. But realistically, there shouldn't even be the need to discuss this in council as long as there are no conflicts between projects. > Jeremy's patch had "VCS Ebuilds should > always be masked or without keywords" which documents current practice, What current practice do you refer to? The extremely low number of package.masked live ebuilds compared to the extremely high number of not package.masked live ebuilds? Note that we are documenting current practice, not Jeremy; and if you try to refer to something else, please refer to it. QA wise I remind you that "mask _or_ unkeyworded" is bad practice towards users; you can then check other situations like "mask _and_ unkeyworded" which is overkill and makes it harder than necessary for the user; which leaves you with "mask" (but then you introduce ~ keywords, ...) or "unkeyworded" (makes sense). I'm yet to see counter arguments for doing something else than "unkeyworded"... > whereas now the documentation has been changed to say that only KEYWORDS="" > is allowed. > > Please also that this also forecloses a pending council decision: > http://www.gentoo.org/proj/en/council/meeting-logs/20131119-summary.txt > (last topic, "Open floor") As long as there are no counter arguments, there is no decision to be made; feel free to put it on the agenda to crowd source counter arguments, but from the prior discussions it seems that this motion is bound to pass... ... especially since only two individuals recommend the opposite without reason; just because someone managed to get it written down somewhere, now I can ask you as well if and where there was a prior discussion for Jeremy's change?
(In reply to Ulrich Müller from comment #15) > (In reply to Markos Chandras from comment #13) > > I merged the pull request for the second patch > > > > http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commit; > > h=5c63d7ec207f1658f75ab82a86d22f69657b8feb > > Sorry, but where was this discussed? Jeremy's patch had "VCS Ebuilds should > always be masked or without keywords" which documents current practice, > whereas now the documentation has been changed to say that only KEYWORDS="" > is allowed. > > Please also that this also forecloses a pending council decision: > http://www.gentoo.org/proj/en/council/meeting-logs/20131119-summary.txt > (last topic, "Open floor") Hmm sorry I thought this was QAs decision.
(In reply to Ulrich Müller from comment #15) > (In reply to Markos Chandras from comment #13) > > I merged the pull request for the second patch > > > > http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commit; > > h=5c63d7ec207f1658f75ab82a86d22f69657b8feb > > Sorry, but where was this discussed? Jeremy's patch had "VCS Ebuilds should > always be masked or without keywords" which documents current practice, > whereas now the documentation has been changed to say that only KEYWORDS="" > is allowed. For what it's worth, I haven't seen any live ebuild with non-empty keywords but with a package.mask entry. Is there such a case or just is it just a it-is-possible-to-happen situation? In my defense, when I see a patch from QA, then I assume that it has passed all the council/qa review cycle before it reaches the devmanual people :) If that's not the case, we need to fix the workflow here :)
(In reply to Tom Wijsman (TomWij) from comment #16) > QA wise I remind you that "mask _or_ unkeyworded" is bad practice towards > users; Why? It's not like any single package would switch forth and back between package.masked and unkeyworded. In fact, there are some situations where having keywords for a live ebuilds is rather convenient. For example, repoman has a --without-mask option which is useful for dependency checking. Or, when making a snapshot, keywords can be carried over from the live ebuild, instead of bothering arch teams with keyword requests. So, I see no reason not to leave this at maintainers' discretion. Also I would assume that live ebuilds are only used by advanced users who should be able to find their way around. > you can then check other situations like "mask _and_ unkeyworded" > which is overkill and makes it harder than necessary for the user; Agreed. > which leaves you with "mask" (but then you introduce ~ keywords, ...) or > "unkeyworded" (makes sense). > > I'm yet to see counter arguments for doing something else than > "unkeyworded"... See above. (In reply to Markos Chandras from comment #18) > For what it's worth, I haven't seen any live ebuild with non-empty keywords > but with a package.mask entry. Is there such a case or just is it just a > it-is-possible-to-happen situation? $ grep 9999 /usr/portage/profiles/package.mask > In my defense, when I see a patch from QA, then I assume that it has passed > all the council/qa review cycle before it reaches the devmanual people :) The only recent discussion that I'm aware of was in the -project ML and I don't see a clear consensus there: http://thread.gmane.org/gmane.linux.gentoo.project/3139 > If that's not the case, we need to fix the workflow here :)
(After talking to ulm...) Guys, now that we have an active QA team again, IMHO this is your playing field. No need to involve the council (otherwise our meetings will have to be weekly one day). Decide on your own, I dont care how (secret vote? hash of cosmic background radiation noise? fistfight at FOSDEM?), and make some stone tablets^H^H^H^H^Hput it in the devmanual.
(In reply to Ulrich Müller from comment #19) > (In reply to Tom Wijsman (TomWij) from comment #16) > > QA wise I remind you that "mask _or_ unkeyworded" is bad practice towards > > users; > > Why? It's not like any single package would switch forth and back between > package.masked and unkeyworded. Think about this from an user view, where the user has to unmask it _or_ accept keywords for it depending how we put; I meant that if we make the policy _or_ that there is no consistency here towards the user. Iotw it makes it more complex for the user, as that user needs to check whether it is masked _or_ unkeyworded which could otherwise just be a simple "add it to ..." instruction. > In fact, there are some situations where having keywords for a live ebuilds > is rather convenient. For example, repoman has a --without-mask option which > is useful for dependency checking. Dependencies on them should always be checked, another reason to not mask them. > Or, when making a snapshot, keywords can be carried over from the live ebuild, We commonly use if [[ ${PV} == *"9999"* ]] constructs for this. > instead of bothering arch teams with keyword requests. Arch teams should always be involved in this if there are no keywords yet. > So, I see no reason not to leave this at maintainers' discretion. Also I > would assume that live ebuilds are only used by advanced users who should be > able to find their way around. Now that could be a possible reason, but I've not seen any maintainer want this; the only occasions where package.mask is used is either by a previous QA team, or because hwoarang pinged me about it for policy reasons (which is the red herring that caused any following discussion regarding this). Towards advanced users, unkeyworded means something like "not old and stable, not even new unstable; but rather bleeding edge with possible risks" whereas a mask means "known to be broken because of ..., bug #..., you can ...". > (In reply to Markos Chandras from comment #18) > > For what it's worth, I haven't seen any live ebuild with non-empty keywords > > but with a package.mask entry. Is there such a case or just is it just a > > it-is-possible-to-happen situation? > > $ grep 9999 /usr/portage/profiles/package.mask `for f in $(grep 9999 /usr/portage/profiles/package.mask) ; do g=$(echo ${f} | sed 's/^.//') ; echo ${f} ; grep KEYWORDS /usr/portage/${g/-9999}/${g#*/}.ebuild ; done` Almost half of them are either KEYWORDS="" or have a conditional on 9999. > > In my defense, when I see a patch from QA, then I assume that it has passed > > all the council/qa review cycle before it reaches the devmanual people :) > > The only recent discussion that I'm aware of was in the -project ML and I > don't see a clear consensus there: > http://thread.gmane.org/gmane.linux.gentoo.project/3139 Well, I don't see disagreement after the replies. (In reply to Andreas K. Hüttel from comment #20) > (After talking to ulm...) Guys, now that we have an active QA team again, > IMHO this is your playing field. No need to involve the council (otherwise > our meetings will have to be weekly one day). Thanks, it wasn't clear when talking with WilliamH whether this would be brought up with the council or not; so, it kept lingering on. Reading up on QA, devmanual etc... as well as remembering the purpose of the council; it doesn't appear necessary unless someone really disagrees, and when someone does and isn't satisfied with an alternative solution we'll let you know. > Decide on your own, I dont > care how (secret vote? hash of cosmic background radiation noise? fistfight > at FOSDEM?), and make some stone tablets^H^H^H^H^Hput it in the devmanual. +1
I feel this bug is getting too much noise and it would be hard to make any decisions (or patches) here. Could you please move this discussion to qa@ (CC devmanual@ if needed)?
(In reply to Markos Chandras from comment #22) > I feel this bug is getting too much noise and it would be hard to make any > decisions (or patches) here. > > Could you please move this discussion to qa@ (CC devmanual@ if needed)? Indeed. Reassigning. My 2 cents here - document current common VCS ebuild maintaining practice, which is as i see in major -9999 ebuilds: - no keywords; - either non-masked(majority) or masked(by some maintainer's decision, though i do not get the point here). Main thing here - tree should be consistent. If something depends on masked version/revision explicitly - it should be masked too. My point of view here: - masked ebuild(no matter if he has keywords or not) can depend on any other; - unmasked and unkeyworded ebuild can NOT depend on masked one; - unmasked and keyworded ebuild can depend on other unmasked ebuilds, basing on their keywords; I do not touch stable situation here, but majority of rules remains the same there.
Here's an attempt of a new wording: In the "Disadvantages of CVS Sources" section, omit mentioning of keywords or masking altogether, because it does not belong there. Instead, add the following as first paragraph of the "Using CVS Sources" section: "CVS ebuilds must be either without KEYWORDS or package.masked (but not both). Empty KEYWORDS are strongly preferred. This applies to "live" ebuilds (-9999) and to ebuilds that extract a static revision but still use CVS for fetching." (And similar change for SVN sources. These sections should be united, as suggested by Diego in comment #2. That's a separate issue, though.) (In reply to Sergey Popov from comment #23) > Main thing here - tree should be consistent. If something depends on masked > version/revision explicitly - it should be masked too. > > My point of view here: > > - masked ebuild(no matter if he has keywords or not) can depend on any other; > - unmasked and unkeyworded ebuild can NOT depend on masked one; > - unmasked and keyworded ebuild can depend on other unmasked ebuilds, basing > on their keywords; > > I do not touch stable situation here, but majority of rules remains the same > there. I believe that these issues are already addressed in <http://devmanual.gentoo.org/keywording/index.html#equal-visibility-requirement> and <http://devmanual.gentoo.org/keywording/index.html#hard-masks>. If something is missing, it should be added there.
I also am in agreement with comment #16. Live ebuilds should not be in package.masked since they do not have keywords, and since there has been no disagreement about this, I do not see the need for council to make a decision.
(In reply to Ulrich Müller from comment #24) > Here's an attempt of a new wording: In the "Disadvantages of CVS Sources" > section, omit mentioning of keywords or masking altogether, because it does > not belong there. Instead, add the following as first paragraph of the > "Using CVS Sources" section: > > "CVS ebuilds must be either without KEYWORDS or package.masked (but not > both). Empty KEYWORDS are strongly preferred. This applies to "live" > ebuilds (-9999) and to ebuilds that extract a static revision but still > use CVS for fetching." > > (And similar change for SVN sources. These sections should be united, as > suggested by Diego in comment #2. That's a separate issue, though.) I gather QA is ok with this wording?
I've seen no objections. Shall I prepare a patch?
(In reply to Ulrich Müller from comment #27) > I've seen no objections. Shall I prepare a patch? That would be awesome!
Created attachment 368100 [details, diff] Patch: Document mask policy for live ebuilds
Looks good to me. Pushed http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commit;h=b071f281912b653b67607cb9a8bb61088a2c07f2
