1 |
Duncan wrote: |
2 |
> William Hubbs posted on Sat, 22 Aug 2009 15:52:54 -0500 as excerpted: |
3 |
> |
4 |
> |
5 |
>> On Sat, Aug 22, 2009 at 08:39:47PM +0100, Ciaran McCreesh wrote: |
6 |
>> |
7 |
>>> We also need to consider whether people even want it done exactly the |
8 |
>>> way Portage does it now. Some developers have expressed a preference |
9 |
>>> for a package.mask.d of some kind instead. |
10 |
>>> |
11 |
>> I saw that, and I'm not sure why they suggested changing the directory |
12 |
>> from package.mask to package.mask.d, since all you would need to do is |
13 |
>> rename the file package.mask to something like package.mask/oldmasks and |
14 |
>> the masks in it would be preserved until you put them in different files |
15 |
>> in the package.mask directory and removed them from oldmasks, ultimately |
16 |
>> deleting oldmasks. |
17 |
>> |
18 |
> |
19 |
> The (one) idea is to keep package.mask as a file for old package managers |
20 |
> that don't know about package.* as a directory yet. Moving package.mask |
21 |
> (the file) to package.mask/oldmasks wouldn't accomplish that. The |
22 |
> scenario people are worried about, is where (for example) someone has |
23 |
> gone away for their year's service (or two, or whatever) that some |
24 |
> nations have, and comes back and tries to upgrade, only to find the tree |
25 |
> is so changed that as soon as they sync, their old package manager is |
26 |
> broken, to the point they can't use use it to upgrade to a new version, |
27 |
> in ordered to be able to upgrade everything else! |
28 |
> |
29 |
> Actually splitting the current single file into multiple files isn't |
30 |
> really a problem, and would probably be done at the same time package.mask |
31 |
> (.d) is made a directory, all in the same commit, so it's nothing to |
32 |
> worry about. |
33 |
> |
34 |
> That said, in this particular instance, I don't believe that should be a |
35 |
> big problem. Why? Because portage has supported it for years already, |
36 |
> and anyone using a PM that doesn't currently support it has by definition |
37 |
> already demonstrated they are reasonably active about their Gentoo based |
38 |
> system management choices, and thus isn't likely to let a system go |
39 |
> unsynced and the PM unupdated for greater than say 90 days anyway. Thus, |
40 |
> when the policy is approved by council, stick a 90-180 day hold on |
41 |
> changing old profiles in the tree, and be done with it. |
42 |
> |
43 |
> So ancient PMs shouldn't be a problem either way, here. Which leaves |
44 |
> only a simple bikeshedding issue, whether people prefer keeping the names |
45 |
> we have, or switching to the *.d forms in keeping with the pattern used |
46 |
> for all those /etc/*.d directories, of which a quick ls here demonstrated |
47 |
> there's about double the number I expected, having never actually counted |
48 |
> them before. While I'd vote for sticking with what we have, that /is/ |
49 |
> just bikeshedding, and I REALLY want to just get on with it, regardless |
50 |
> of what it's named, as the feature really is quite useful. |
51 |
> |
52 |
> |
53 |
|
54 |
While I like your example, if this were to happen and a couple other |
55 |
things has been updated, like for example expat a while back and other |
56 |
similar update nightmares, wouldn't a reinstall be easier and most |
57 |
likely recommended anyway? I have seen this recommended and even made |
58 |
that recommendation on -user a few times. I would also do a reinstall |
59 |
on my own system if I had been gone for 6 months or more. With the |
60 |
updates coming pretty fast for most things, you would most likely |
61 |
recompile most everything on the system anyway. Save the configs and |
62 |
the world file and just start over from a very fresh stage tarball. |
63 |
|
64 |
It is good to look out for those braves souls that would try to update |
65 |
anyway but thought it worth a mention. Would upgrading be recommended? |
66 |
|
67 |
< back to my hole > |
68 |
|
69 |
Dale |
70 |
|
71 |
:-) :-) |