From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: QA: package.mask policies
Date: Sun, 8 Nov 2009 01:25:24 +0000 (UTC) [thread overview]
Message-ID: <pan.2009.11.08.01.25.23@cox.net> (raw)
In-Reply-To: 8b4c83ad0911071608n7ebc31dcy6e7eb1d9470b3067@mail.gmail.com
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 soooo 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
next prev parent reply other threads:[~2009-11-08 1:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-07 17:24 [gentoo-dev] QA: package.mask policies Tomáš Chvátal
2009-11-07 18:03 ` William Hubbs
2009-11-07 18:33 ` [gentoo-dev] " Christian Faulhammer
2009-11-07 18:56 ` William Hubbs
2009-11-07 19:03 ` Duncan
2009-11-08 0:08 ` Nirbheek Chauhan
2009-11-08 1:25 ` Duncan [this message]
2009-11-08 23:46 ` Vlastimil Babka
2009-11-08 1:26 ` Kent Fredric
2009-11-08 15:13 ` Christian Faulhammer
2009-11-09 13:17 ` Duncan
2009-11-08 12:41 ` [gentoo-dev] " Peter Volkov
2009-11-08 16:57 ` Jeroen Roovers
2009-11-08 17:20 ` Tomáš Chvátal
2009-11-11 16:43 ` Jeroen Roovers
2009-11-11 17:11 ` [gentoo-dev] " Torsten Veller
2009-11-11 21:54 ` Jeroen Roovers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2009.11.08.01.25.23@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox