| 1 |
Brian Harring posted on Sun, 09 Sep 2012 15:10:27 -0700 as excerpted: |
| 2 |
|
| 3 |
> [Current profile config to to mask the USE=introspection |
| 4 |
> globally, but unmask it for app-crypt/gcr]: |
| 5 |
> |
| 6 |
> use.mask: |
| 7 |
> introspection |
| 8 |
> |
| 9 |
> package.use.mask: |
| 10 |
> app-crypt/gcr -introspection |
| 11 |
|
| 12 |
> [Suggest killing package.* content, folding it into use.*] |
| 13 |
|
| 14 |
> use.mask: |
| 15 |
> * introspection |
| 16 |
> app-cryt/gcr -introspection |
| 17 |
|
| 18 |
> Specifically, collapsing: |
| 19 |
> package.use.mask, use.mask -> use.mask |
| 20 |
> package.use.force, use.force -> use.force |
| 21 |
> package.use.stable.mask, use.stable.mask -> use.stable.mask |
| 22 |
> package.use.stable.force, use.stable.force -> use.stable.force |
| 23 |
|
| 24 |
You mention doing this for the profile. |
| 25 |
|
| 26 |
?? Would user's package.* and general make.conf settings remain the same? |
| 27 |
|
| 28 |
?? What about user's existing /etc/portage/profile overrides, if any? |
| 29 |
|
| 30 |
?? Are you proposing the change be only for new profiles, eventually |
| 31 |
deprecating the old ones, thus having the PMs (and devs maintaining |
| 32 |
profiles) support both methods for awhile much as the cascading profiles |
| 33 |
migration was handled? By definition, at least user's current /etc/ |
| 34 |
portage/profile/ settings are in the current format, so if you continue |
| 35 |
to support that, you'll in effect continue to support the old profile |
| 36 |
format, and (from the PM viewpoint) migration might as well be via new |
| 37 |
profiles and current profile deprecation, but that will force profile |
| 38 |
maintainers to maintain both for whatever period. |
| 39 |
|
| 40 |
?? And if they change, are you proposing a script that a user can run to |
| 41 |
automate the process, or simply a news item pointing to the appropriate |
| 42 |
gentoo profile upgrade documentation page, or ?? |
| 43 |
|
| 44 |
|
| 45 |
In general, the idea seems like an eventual efficiency gain and I'm not |
| 46 |
opposed, but I do wonder if the gain is actually going to be worth it in |
| 47 |
practice, given the above. Still, I'm not opposed, but I tend to be |
| 48 |
rather more leading edge and less opposed to change than most users in |
| 49 |
any case, and I'd guess a significant number of both users and devs that |
| 50 |
will be trying to support them (and both sets of profiles if the profile |
| 51 |
deprecation and upgrade migration method is chosen), will have rather |
| 52 |
stronger ideas about the practical cost/benefit ratio of such a change. |
| 53 |
|
| 54 |
-- |
| 55 |
Duncan - List replies preferred. No HTML msgs. |
| 56 |
"Every nonfree program has a lord, a master -- |
| 57 |
and if you use the program, he is your master." Richard Stallman |
Archives