Re: [gentoo-dev] Request for testing

[Charles Lacour]

On Wednesday 14 August 2002 10:33, you wrote:
> Hi All,
>
> As subscribers to this list, I'd reckon a lot of you would like to help
> out testing some of the masked stuff.  The list of stuff "masked for
> testing" in /usr/portage/profiles/package.mask grows daily, and we have a
> dire need for userland testers.  So, if some of you brave souls would care
> to test and report bugs, that would be EXCEEDINGLY helpful, and the
> development team would be equally as grateful.  Things which need testing
> are:
>
> sh-utils
> bison
> util-linux
> zsh
> xine
> mplayer
> vlc
> pinepgp
>
> and there are some KDE apps as well, I think.
>
> Thanks,

I'm willing enough to play beta-tester for the things I use a lot, but I'd 
like to be sure I know how to get back to what works, especially if it's 
something like fileutils.

I thought I saw somebody say something like "unmask sh-utils-2.0.14", but I 
can't find any such command. Digging deeper in the cellar of my brain, I 
remember something about commenting/uncommenting stuff in a file. I bit of 
digging and I found "/usr/portage/profiles/package.mask".

I'm going to assume that's what I play with and describe the whole process of 
unmasking something, installing it, testing it, re-masking it and getting 
back the original version (or the latest version decreed stable, at least.)

I'd like critiques and suggestions for simplifying it, making it safe, etc. 
(UPDATE: I got halfway through and started writing it as tutorial for 
newbies. Yes, it's long -- I'm wordy. I still want to know if it's correct.)






I'm going to use the sys-apps/sh-utils-2.0.14 package as my example.

1. Note down a few useful tidbits of information, like what version you're on 
now. ("qpkg -l sh-utils", or "emerge search sh-utils"). Consider doing an 
"emerge rsync" before you start. If an "emerge search sh-utils" shows a 
different version that what you're running, caution is advised -- it may not 
be simple and easy (or even possible) to go back to the version you're 
running now. If you think you may want to go back to a version that no longer 
exists in the portage tree, make sure you still have the ebuild and the 
tarball. (You should be able to find the ebuild in 
/var/db/pkg/<group-name>/<package name>  (e.g. 
/var/db/pkg/sys-apps/sh-utils-2.0.11-r5) if it's no longer in /usr/portage.

If you don't have the tarball in /usr/portage/distfiles and it's no longer on 
the Gentoo servers, you're screwed. You _are_ going to be upgrading if you 
change anything.

2. Edit /usr/portage/profiles/package.mask. You don't need to make a backup, 
as a "emerge rsync" will put it back like it was (possibly with updates if 
it's been awhile since you last rsync'd.)

3. Find the package you wish to experiment with, and comment it out. 
(Using the sh-utils present on 2002/08/14 as the example, it was:
=sys-apps/sh-utils-2.0.14

change it to:

#=sys-apps/sh-utils-2.0.14

Adding another comment with your initials and the date or something like that 
will make it easier to find your changes later if you need to.

4. "emerge -p sh-utils".  This should show you the newly unmasked package.

5. "emerge sh-utils" (or possibly "emerge sh-utils-2.0.14". Since it should 
be the latest package (else why have it masked?), specifying the version 
shouldn't be necessary.)

6. Play around with the new stuff. Find bugs, try to make them reproducible, 
post a bug report in bugzilla.


Assuming it's broken and you want to go back to something that works:

7. Edit /usr/portage/profiles/package.mask, and uncomment the line you 
commented out earlier. (Or "emerge rsync", if it's about that time anyway.)

8. "emerge -p sh-utils"  (This should show you the latest stable (i.e. 
unmasked) version. Depending, this may be the same one you were using before. 
Since you didn't skip over step 1, you know, right?  <evil grin>

9. Assuming you're happy with the version "emerge -p" reported, "emerge 
sh-utils".

10. No, you're not quite finished yet. "emerge unmerge sh-utils-2.0.14". It's 
still there.  Gentoo does things a little different than most distributions. 
With something like Red Hat, the safest way to change back to an old package 
is "rpm -e <bad package>", then "rpm -i <good package>". Gentoo has a 
database (in /var/db, if you're curious) that records which package owns each 
file. By emerging the good package first, you take away ownership from the 
bad package of any files the good and bad package may have in common. Then 
when you unmerge the bad package, the only things that get deleted are the 
files belonging exclusively to the bad package.

This is Gentoo's recommended way of changing any version: emerge the new 
package first, then unmerge the old one.

Unmerging the old one first, then merging the new one will _usually_ work, 
but if you plan to do it this way, be sure to say to yourself "Ok, now I'm 
going to do it the WRONG way, just to see what happens. Hope I don't have to 
rebuild the entire system to fix things..."  (This will keep you properly 
humble and apologetic if you have to report something like "I lost cp, mv, 
cat, and dd. How do I fix this, please?")