Ühel kenal päeval, N, 29.12.2016 kell 20:51, kirjutas Marc Schiffbauer: > * Ulrich Mueller schrieb am 29.12.16 um 16:52 Uhr: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 29 Dec 2016, Marc Schiffbauer wrote: > > > > > > > > I'd prefer "package versions" but the people will come up with > > > "sys-apps/eix-1.2.3" or just "1.2.3", not the desired > > > "=sys-apps/eix-1.2.3". > > > > Why would the equals sign be needed there? > > I supposed it to do because I assumed that we are not going to > change > the expected values.
To my knowledge the sanity checking tool doesn't care either way. I've been adding the = in front for now just in case it helps arch teams to more directly copy-paste the list to their package.accept_keywords or whatnot. I'm sure any further tooling like "app-portage/tatt" can or will be able to handle it either way for the arch dev too. > But yes, propably only listing the PV would be enough. You mean PVR, or rather $CATEGORY/$PF. As my own worthless 2 dimes on the field naming bikeshed, I'd suggest "Package revisions" (as opposed to just versions). Additionally I would like such a package revision list or in this case even ranges to be used outside stabling/keywording as well. For marking up which package and revision fixes a given bug, as to do independent semi-automatic tracking of bugs that still affect the stable tree. But that's a bikeshed and discussion for next year, once the tooling that could make good use of that gets further along and into this area of topics. Initial thought was to have it as a separate field anyways then, sort of like the one that shows up for RESOLVED DUPLICATE closing of bugs, but for RESOLVED FIXED or some such. Anyways, that's for another thread, another year :) Mart
