On Wed, 10 Sep 2014 13:56:04 +0000 hasufell <hasuf...@gentoo.org> wrote:
> Tom Wijsman: > > On Tue, 09 Sep 2014 19:12:28 +0000 > > hasufell <hasuf...@gentoo.org> wrote: > > > >> Jauhien Piatlicki: > >>> > >>> When I accept ~arch I expect that no live ebuilds will be built. I > >>> think other gentoo users expect the same. > >> > >> Just because users are used to it doesn't make it better. > > > > How does it "make it better" for users that are used to what works > > well? > > It improves usability by providing additional information. Usability is not to be found in information that is subject to change. > >>> Emerging live ebuild usually is quite a risky thing, so hiding > >>> such stuff behind dropped keywords is quite reasonable. > >> > >> That's why you can mask them. > > > > Masking is for packages that are known to be broken, not for risks. > > PMS doesn't specify what exactly package.mask is for, so scm ebuilds > is a perfectly valid use case, unless you can come up with an > alternative that is not wrong like empty KEYWORDS. That something is not in PMS does not make it a valid use case; the Portage tree is subject to more specifications, like for example that the devmanual has a very specific paragraph on this case: "CVS ebuilds must be either with empty 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." http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources We can also find more about empty keywords: "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." http://devmanual.gentoo.org/keywording So, both quotes reveal that empty keywords fit very well; package.mask rather fits when there is a good reason to it, especially since the idea of QA is to keep package.mask maintainable by limiting its length. In doing so, QA can keep an eye on what is broken; which allows either fixing or removing ebuilds that stay there too long. In this context, a masked live ebuild would be interpreted as a live ebuild that fails to fetch, compile or run for a prolonged time; eg. due to an inactive or dead upstream, or an upstream that refuses to support that broken part. > >> The same flawed logic of empty KEYWORDS could actually be applied > >> to any ebuild variable. > >> You say "we can't test if it works for all these architectures > >> reliably and for every single commit". > >> Yeah, same goes for dependencies, license and even the description. > >> Because it's a live ebuild, all of them can change. KEYWORDS is no > >> special exception. > > > > KEYWORDS is a special exception because it involves arch testing. > > Yes, and you hide this information from the user. Information that is a given; as known, live ebuilds miss arch testing.
