public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <caster@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev]  Re: QA: package.mask policies
Date: Mon, 09 Nov 2009 00:46:40 +0100	[thread overview]
Message-ID: <4AF75860.30300@gentoo.org> (raw)
In-Reply-To: <pan.2009.11.08.01.25.23@cox.net>

Duncan wrote:
> 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?

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



  reply	other threads:[~2009-11-08 23:46 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
2009-11-08 23:46           ` Vlastimil Babka [this message]
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=4AF75860.30300@gentoo.org \
    --to=caster@gentoo.org \
    --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