Please do not unmask live ebuilds. Reproducible: Always
Could you point me to the actual rule for this? You can unmask 9999 ebuilds as long as they are not keyworded methinks.
(In reply to Matthew Thode ( prometheanfire ) from comment #1) > Could you point me to the actual rule for this? You can unmask 9999 ebuilds > as long as they are not keyworded methinks. I can't (I'm not a lower, just a country doctor), but I can give you few reasons: 1. From Dev manual http://devmanual.gentoo.org/keywording/index.html: "No keyword If a package has no keyword for a given arch, it means it is not known whether the package will work, or that insufficient testing has occurred for ~arch." "no known .. will work, .. insufficient testing..." is a pretty much given for live ebuilds. 2. Consistency. Try to grep KEYWORDS in */*/*-9999.ebuild 3. There are no stable version. 4. I did say magic word. Thanks, Vadim.
All of the openstack ebuilds have 9999 releases that are not keyworded. Same for git branch based ebuilds (2014.1.9999). There are 4 levels of stability. 1. stable 2. keyworded 3. unkeyworded 4. masked Live ebuilds fall under 3, also although 9999 is generally bad, the openstack ebuilds get a TON of testing before merging (they removed a bunch of stuff from one openstack project for not having enough testing).
(In reply to Matthew Thode ( prometheanfire ) from comment #3) > All of the openstack ebuilds have 9999 releases that are not keyworded. > Same for git branch based ebuilds (2014.1.9999). You did keyword python-keystoneclient-9999.ebuild: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-python/python-keystoneclient/python-keystoneclient-9999.ebuild?r1=1.9&r2=1.10 Please explain why? > > There are 4 levels of stability. > > 1. stable > 2. keyworded > 3. unkeyworded > 4. masked > > Live ebuilds fall under 3, Yes 3. That what I said. Why did you keyward it? That is just sloppy!
because I coppied the newest ebuild to update it and forgot to remove the keywords.
