1 |
On Wednesday 14 August 2002 10:33, you wrote: |
2 |
> Hi All, |
3 |
> |
4 |
> As subscribers to this list, I'd reckon a lot of you would like to help |
5 |
> out testing some of the masked stuff. The list of stuff "masked for |
6 |
> testing" in /usr/portage/profiles/package.mask grows daily, and we have a |
7 |
> dire need for userland testers. So, if some of you brave souls would care |
8 |
> to test and report bugs, that would be EXCEEDINGLY helpful, and the |
9 |
> development team would be equally as grateful. Things which need testing |
10 |
> are: |
11 |
> |
12 |
> sh-utils |
13 |
> bison |
14 |
> util-linux |
15 |
> zsh |
16 |
> xine |
17 |
> mplayer |
18 |
> vlc |
19 |
> pinepgp |
20 |
> |
21 |
> and there are some KDE apps as well, I think. |
22 |
> |
23 |
> Thanks, |
24 |
|
25 |
I'm willing enough to play beta-tester for the things I use a lot, but I'd |
26 |
like to be sure I know how to get back to what works, especially if it's |
27 |
something like fileutils. |
28 |
|
29 |
I thought I saw somebody say something like "unmask sh-utils-2.0.14", but I |
30 |
can't find any such command. Digging deeper in the cellar of my brain, I |
31 |
remember something about commenting/uncommenting stuff in a file. I bit of |
32 |
digging and I found "/usr/portage/profiles/package.mask". |
33 |
|
34 |
I'm going to assume that's what I play with and describe the whole process of |
35 |
unmasking something, installing it, testing it, re-masking it and getting |
36 |
back the original version (or the latest version decreed stable, at least.) |
37 |
|
38 |
I'd like critiques and suggestions for simplifying it, making it safe, etc. |
39 |
(UPDATE: I got halfway through and started writing it as tutorial for |
40 |
newbies. Yes, it's long -- I'm wordy. I still want to know if it's correct.) |
41 |
|
42 |
|
43 |
|
44 |
|
45 |
|
46 |
|
47 |
I'm going to use the sys-apps/sh-utils-2.0.14 package as my example. |
48 |
|
49 |
1. Note down a few useful tidbits of information, like what version you're on |
50 |
now. ("qpkg -l sh-utils", or "emerge search sh-utils"). Consider doing an |
51 |
"emerge rsync" before you start. If an "emerge search sh-utils" shows a |
52 |
different version that what you're running, caution is advised -- it may not |
53 |
be simple and easy (or even possible) to go back to the version you're |
54 |
running now. If you think you may want to go back to a version that no longer |
55 |
exists in the portage tree, make sure you still have the ebuild and the |
56 |
tarball. (You should be able to find the ebuild in |
57 |
/var/db/pkg/<group-name>/<package name> (e.g. |
58 |
/var/db/pkg/sys-apps/sh-utils-2.0.11-r5) if it's no longer in /usr/portage. |
59 |
|
60 |
If you don't have the tarball in /usr/portage/distfiles and it's no longer on |
61 |
the Gentoo servers, you're screwed. You _are_ going to be upgrading if you |
62 |
change anything. |
63 |
|
64 |
2. Edit /usr/portage/profiles/package.mask. You don't need to make a backup, |
65 |
as a "emerge rsync" will put it back like it was (possibly with updates if |
66 |
it's been awhile since you last rsync'd.) |
67 |
|
68 |
3. Find the package you wish to experiment with, and comment it out. |
69 |
(Using the sh-utils present on 2002/08/14 as the example, it was: |
70 |
=sys-apps/sh-utils-2.0.14 |
71 |
|
72 |
change it to: |
73 |
|
74 |
#=sys-apps/sh-utils-2.0.14 |
75 |
|
76 |
Adding another comment with your initials and the date or something like that |
77 |
will make it easier to find your changes later if you need to. |
78 |
|
79 |
4. "emerge -p sh-utils". This should show you the newly unmasked package. |
80 |
|
81 |
5. "emerge sh-utils" (or possibly "emerge sh-utils-2.0.14". Since it should |
82 |
be the latest package (else why have it masked?), specifying the version |
83 |
shouldn't be necessary.) |
84 |
|
85 |
6. Play around with the new stuff. Find bugs, try to make them reproducible, |
86 |
post a bug report in bugzilla. |
87 |
|
88 |
|
89 |
Assuming it's broken and you want to go back to something that works: |
90 |
|
91 |
7. Edit /usr/portage/profiles/package.mask, and uncomment the line you |
92 |
commented out earlier. (Or "emerge rsync", if it's about that time anyway.) |
93 |
|
94 |
8. "emerge -p sh-utils" (This should show you the latest stable (i.e. |
95 |
unmasked) version. Depending, this may be the same one you were using before. |
96 |
Since you didn't skip over step 1, you know, right? <evil grin> |
97 |
|
98 |
9. Assuming you're happy with the version "emerge -p" reported, "emerge |
99 |
sh-utils". |
100 |
|
101 |
10. No, you're not quite finished yet. "emerge unmerge sh-utils-2.0.14". It's |
102 |
still there. Gentoo does things a little different than most distributions. |
103 |
With something like Red Hat, the safest way to change back to an old package |
104 |
is "rpm -e <bad package>", then "rpm -i <good package>". Gentoo has a |
105 |
database (in /var/db, if you're curious) that records which package owns each |
106 |
file. By emerging the good package first, you take away ownership from the |
107 |
bad package of any files the good and bad package may have in common. Then |
108 |
when you unmerge the bad package, the only things that get deleted are the |
109 |
files belonging exclusively to the bad package. |
110 |
|
111 |
This is Gentoo's recommended way of changing any version: emerge the new |
112 |
package first, then unmerge the old one. |
113 |
|
114 |
Unmerging the old one first, then merging the new one will _usually_ work, |
115 |
but if you plan to do it this way, be sure to say to yourself "Ok, now I'm |
116 |
going to do it the WRONG way, just to see what happens. Hope I don't have to |
117 |
rebuild the entire system to fix things..." (This will keep you properly |
118 |
humble and apologetic if you have to report something like "I lost cp, mv, |
119 |
cat, and dd. How do I fix this, please?") |