Re: [gentoo-dev] Re: QA: package.mask policies
On Wed, 11 Nov 2009 18:11:37 +0100 Torsten Veller wrote: > > Tomáš Chvátal wrote: > > > But if we look on tag of screen-4.0.3 or its release: > > > screen-4.0.3.tar.gz07-Aug-2008 06:30 821K > > > screen-4.0.3.tar.gz.sig07-Aug-2008 06:30 65 > > *screen-4.0.3 (25 Oct 2006) > > Part of the famous "Software from the future" series. > Proudly presented by your Gentoo time travel agency. Yes, corrected again. The original came out in 2006, whatever the timestamp on the site says. The _p* was a CVS snapshot that was added to the tree years later. I'll get me coat, jer
[gentoo-dev] Re: QA: package.mask policies
> Tomáš Chvátal wrote: > > But if we look on tag of screen-4.0.3 or its release: > > screen-4.0.3.tar.gz07-Aug-2008 06:30 821K > > screen-4.0.3.tar.gz.sig07-Aug-2008 06:30 65 *screen-4.0.3 (25 Oct 2006) Part of the famous "Software from the future" series. Proudly presented by your Gentoo time travel agency.
[gentoo-dev] Re: QA: package.mask policies
Christian Faulhammer posted on Sun, 08 Nov 2009 16:13:22 +0100 as excerpted: > Duncan <1i5t5.dun...@cox.net>: >> 1) Users using ** in their package.keywords file should know enough >> about what they're doing to use their own package.mask, as well. If >> they're using ** in the keywords file, they're /saying/ they're reading >> to handle such things, after all, why shouldn't we let them? > > They do it, because they don't know what they are doing. Just seen it > somewhere, heard about it. During LinuxTag the question why ** unmasks > some live ebuilds occured at least three times. Real user question numbers like that are useful to know. Thanks. Sure beats general hand-wavy arguments (like mine too, was). =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: QA: package.mask policies
Duncan wrote: In theory that's what those stupid version string thingys are for, but it's s much easier just to forget one! =:^[ Maybe something about this should go in the handbook -- a suggestion that if one is going to use a package.unmask entry, that they copy the package.mask entry over, thus at least letting the devs minimize the version spread damage with their package.mask entries. That's what I've started doing, and it works surprisingly well, as I have right there the comment on why it was masked (and add a comment on why I'm unmasking, when I think I might wonder, later), and it's the exact same versions the devs masked in the first place, so I don't have to worry so much about unintended version spread -- at least as long as the devs doing the masking worried about it then. =:^) What do you devs think? Would that be a practical hint for the handbook? Would it be helpful in allowing /you/ to control the version spread of the unmask, by consequence of your control of the version spread on the mask in the first place? Hi, handbook is one thing, but maybe portage could make it more prominent when it displays the packages to be merged, so that the users hopefuly notice? - visibly distinguish (red color and stuff?) packages that are to be installed thanks to package.unmask or ** keyword - print extra warnings about those entries in package.unmask and ** keywords that are not version restricted, if they contain the packages to be merged. This could follow the suggestion above - aside from the distinguished packages, below the list and above the yes/no (if --ask is used) there would be "Warning: the following packages have broad unmasks, you sure you want these versions?" and the list. Vlastimil
[gentoo-dev] Re: QA: package.mask policies
Hi, Duncan <1i5t5.dun...@cox.net>: > 1) Users using ** in their package.keywords file should know enough > about what they're doing to use their own package.mask, as well. If > they're using ** in the keywords file, they're /saying/ they're > reading to handle such things, after all, why shouldn't we let them? They do it, because they don't know what they are doing. Just seen it somewhere, heard about it. During LinuxTag the question why ** unmasks some live ebuilds occured at least three times. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Re: QA: package.mask policies
On Sun, Nov 8, 2009 at 1:08 PM, Nirbheek Chauhan wrote: > On Sun, Nov 8, 2009 at 12:33 AM, Duncan <1i5t5.dun...@cox.net> wrote: > > 2) That won't necessarily stop the bugs from rolling in. Some devs may > > get tired of live pkg bugs and package.mask it, thus putting up a double- > > barrier to the live ebuild. If users jump BOTH barriers and fall over > > the ledge, well... maybe they /need/ that Darwin Award! =:^] > > > > We had something interesting happen with policykit. It was masked for > a very long time, and so all users of policykit had > "sys-auth/policykit" in p.unmask. Then it was unmasked, but of course > who bothers cleaning up their local configuration as long as it works? > > Months later, policykit-0.92 was added (masked) which was ABI, API, > UI, everything incompatible. Naturally portage on said users' boxes > was very happy to see such an update on the system and it very > promptly upgraded policykit. > > And of course it completely hosed everything on top of X. > > We received bug reports for this a *long* time after adding it. After > getting sick of duping, and since the new ebuild was broken in a few > ways too (and we had decided to rename policykit-0.92 it to > sys-auth/polkit), we finally decided to remove it. > > Lesson to be learnt: users are morons with short attention spans[1]. > But we cannot ignore that fact. > > > In such cases users should be using version specific/version ranges for p.keywords/p.unmask. I don't recall seeing much literature on this practice though with regards to standard recommendations of users and how they should use their own p.keywords and p.unmask. Maybe a good standard practice would be to *not* use ranged p.masks and have explicit =version p.masks, so that users who use the commonly available scripts that just copy from p.mask to p.unmask don't get silently bitten as a consequence. -- Kent perl -e "print substr( \"edrgmaM SPA nocomil.i...@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
[gentoo-dev] Re: QA: package.mask policies
Nirbheek Chauhan posted on Sun, 08 Nov 2009 05:38:56 +0530 as excerpted: > We had something interesting happen with policykit. It was masked for a > very long time, and so all users of policykit had "sys-auth/policykit" > in p.unmask. Then it was unmasked, but of course who bothers cleaning up > their local configuration as long as it works? > > Months later, policykit-0.92 was added (masked) which was ABI, API, UI, > everything incompatible. > And of course it completely hosed everything on top of X. > Lesson to be learnt: users are morons with short attention spans[1]. > 1. Of course, we ourselves come under the definition of "users" too.. ;) Ouch! I've had something like that bite me (user-side) too, when I wondered why my package.mask entry wasn't being honored... I had a package.unmask entry too! In theory that's what those stupid version string thingys are for, but it's s much easier just to forget one! =:^[ Maybe something about this should go in the handbook -- a suggestion that if one is going to use a package.unmask entry, that they copy the package.mask entry over, thus at least letting the devs minimize the version spread damage with their package.mask entries. That's what I've started doing, and it works surprisingly well, as I have right there the comment on why it was masked (and add a comment on why I'm unmasking, when I think I might wonder, later), and it's the exact same versions the devs masked in the first place, so I don't have to worry so much about unintended version spread -- at least as long as the devs doing the masking worried about it then. =:^) What do you devs think? Would that be a practical hint for the handbook? Would it be helpful in allowing /you/ to control the version spread of the unmask, by consequence of your control of the version spread on the mask in the first place? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: QA: package.mask policies
On Sun, Nov 8, 2009 at 12:33 AM, Duncan <1i5t5.dun...@cox.net> wrote: > 2) That won't necessarily stop the bugs from rolling in. Some devs may > get tired of live pkg bugs and package.mask it, thus putting up a double- > barrier to the live ebuild. If users jump BOTH barriers and fall over > the ledge, well... maybe they /need/ that Darwin Award! =:^] > We had something interesting happen with policykit. It was masked for a very long time, and so all users of policykit had "sys-auth/policykit" in p.unmask. Then it was unmasked, but of course who bothers cleaning up their local configuration as long as it works? Months later, policykit-0.92 was added (masked) which was ABI, API, UI, everything incompatible. Naturally portage on said users' boxes was very happy to see such an update on the system and it very promptly upgraded policykit. And of course it completely hosed everything on top of X. We received bug reports for this a *long* time after adding it. After getting sick of duping, and since the new ebuild was broken in a few ways too (and we had decided to rename policykit-0.92 it to sys-auth/polkit), we finally decided to remove it. Lesson to be learnt: users are morons with short attention spans[1]. But we cannot ignore that fact. 1. Of course, we ourselves come under the definition of "users" too.. ;) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: QA: package.mask policies
Christian Faulhammer posted on Sat, 07 Nov 2009 19:33:12 +0100 as excerpted: > William Hubbs : >> > * Masking live... >> > Heck no. This is not proper usage. Just use keywords mask. >> > KEYWORDS="". Problem solved and the package.mask is smaller. (Note, >> > in overlays do what ever you want, since it does not polute the main >> > mask from g-x86). >> >> True. If we mask live ebuilds with KEYWORDS="", there isn't a reason >> to put them in p.mask that I can think of. > > Many users use "**" in their p.keywords file and get a live ebuild > then. There's two different ways of seeing that. 1) Users using ** in their package.keywords file should know enough about what they're doing to use their own package.mask, as well. If they're using ** in the keywords file, they're /saying/ they're reading to handle such things, after all, why shouldn't we let them? 2) That won't necessarily stop the bugs from rolling in. Some devs may get tired of live pkg bugs and package.mask it, thus putting up a double- barrier to the live ebuild. If users jump BOTH barriers and fall over the ledge, well... maybe they /need/ that Darwin Award! =:^] Thus I can see either way. If a dev's sick of dealing with live package bugs, maybe a package.mask will keep a few more folks from jumping over that ledge and filing them. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: QA: package.mask policies
On Sat, Nov 07, 2009 at 07:33:12PM +0100, Christian Faulhammer wrote: > Hi, > > William Hubbs : > > > * Masking live... > > > Heck no. This is not proper usage. Just use keywords mask. > > > KEYWORDS="". Problem solved and the package.mask is smaller. (Note, > > > in overlays do what ever you want, since it does not polute the > > > main mask from g-x86). > > > > True. If we mask live ebuilds with KEYWORDS="", there isn't a reason > > to put them in p.mask that I can think of. > > Many users use "**" in their p.keywords file and get a live ebuild > then. If a user runs ~arch even for one package, they should be able to recover if things break temporarily. So, if they are putting ** in their package.keywords for packages, that is another level past ~arch to me. They should definitely be able to recover in that situation. -- William Hubbs gentoo accessibility team lead willi...@gentoo.org pgphl6oorkDVm.pgp Description: PGP signature
[gentoo-dev] Re: QA: package.mask policies
Hi, William Hubbs : > > * Masking live... > > Heck no. This is not proper usage. Just use keywords mask. > > KEYWORDS="". Problem solved and the package.mask is smaller. (Note, > > in overlays do what ever you want, since it does not polute the > > main mask from g-x86). > > True. If we mask live ebuilds with KEYWORDS="", there isn't a reason > to put them in p.mask that I can think of. Many users use "**" in their p.keywords file and get a live ebuild then. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
