[gentoo-amd64] Following the kde4.1 upgrade guide

[gentoo-amd64] Following the kde4.1 upgrade guide

[Mark Haney]

I'm finally to the point that I'm read yo move to KDE4.1.2 now, but I'm 
missing something I think.

Using the KDE4.1 guide, I try to unmerge the KDE4.1.1 packages using 
sets (as the guide states to do if you're using the kdesvn-portage 
overlay), but it doesn't work. I apparently don't have any sets when I 
setup the overlay?

I've upgraded portage so I know it's a version that supports sets, but 
for some reason it's not working.

Ideas?

-- 
Libenter homines id quod volunt credunt -- Caius Julius Caesar


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support

[gentoo-amd64] Re: Following the kde4.1 upgrade guide

[Duncan]

"Mark Haney" <mhaney@ercbroadband.org> posted
4906004B.4030707@ercbroadband.org, excerpted below, on  Mon, 27 Oct 2008
13:54:19 -0400:

> I'm finally to the point that I'm read yo move to KDE4.1.2 now, but I'm
> missing something I think.
> 
> Using the KDE4.1 guide, I try to unmerge the KDE4.1.1 packages using
> sets (as the guide states to do if you're using the kdesvn-portage
> overlay), but it doesn't work. I apparently don't have any sets when I
> setup the overlay?
> 
> I've upgraded portage so I know it's a version that supports sets, but
> for some reason it's not working.
> 
> Ideas?

Well, first off as all the kdesvn and earlier kde-4 packages were masked 
and you had to unmask them for installation, it should be a simple matter 
of deleting all those package.unmask entries you added to unmask them, 
running emerge --update, and portage should take care of the details on 
its own.  Of course, don't forget the --depclean and revdep-rebuild steps 
afterward, cleaning up the loose ends. Given the flexibility of portage, 
there are several other ways to do it, some of which are listed below, 
but this might be the simplest, particularly since you should really do 
it anyway, thus cleaning up your portage config after your testing.

As for the other ways...

Note that the upgrade guide mentions sets (under installation in the 
guide) , providing a link to the overlay versions, since the sets 
themselves aren't in the tree yet.  There's a kde-4 set, listing all 
kde-4 packages complete with :kde-4 slot specifiers.

If you were using the kde-4 slot, removal should be a simple as pointing 
emerge --unmerge at that set.

It's the "raw" link if you're downloading from the git tree, or unpack 
the tarball somewhere, browse it if desired, and point portage at it.  
Note that the default sets directory is /etc/portage/sets.  You can 
unpack the tarball there if desired (I did), but you may also find that 
too cluttered, and unpack it elsewhere and either point portage at your 
chosen location specifically or copy/move specific sets as needed to the 
default location, thus avoiding the clutter and confusion of all those 
extra sets you may not use.

If you were using the kdesvn slot or something else, you should be able 
to do the same, only use your favorite text editor to search-and-replace 
all the ":kde-4" slot specifiers with the appropriate slot as necessary.

As the upgrade guide mentions, don't forget --depclean.  Of course, 
that'll be much simpler and less prone to error if you've maintained a 
clean install all along.  (Of course, don't forget --ask or --pretend 
before actually doing it, either, but that should be habit, by now, and 
should go without saying.)

If you used kde-prefix or packages from before that USE flag was 
introduced, you can also try the unmerge example using qfile.  
Alternatively you can use equery belongs /usr/kde/%PREFIX% 
(replace %PREFIX% as necessary) to get a list of packages using that 
directory, and unmerge all of them.

If you don't have kde-3 merged, or do but don't care if it gets unmerged, 
you can also use the generic kde sets from the location above, and/or use 
emerge --pretend --emptytree | grep kde > kdepkg.lst to get a list, edit 
that file to format it correctly for feeding back to emerge, then use 
that as an unmerge list.  I've done the emptytree grep thing (using cut 
and etc to trim it down further as well) myself a few times on various 
things.  When the packages weren't masked and before sets, it was at 
times necessary to do something like that, particularly with slotted 
split package projects like kde-3.  The proper use of sets should 
dramatically ease the problem in the future. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: Following the kde4.1 upgrade guide

[Mark Haney]

Duncan wrote:
> "Mark Haney" <mhaney@ercbroadband.org> posted
> 4906004B.4030707@ercbroadband.org, excerpted below, on  Mon, 27 Oct 2008
> 13:54:19 -0400:
> 
>> I'm finally to the point that I'm read yo move to KDE4.1.2 now, but I'm
>> missing something I think.
>>
>> Using the KDE4.1 guide, I try to unmerge the KDE4.1.1 packages using
>> sets (as the guide states to do if you're using the kdesvn-portage
>> overlay), but it doesn't work. I apparently don't have any sets when I
>> setup the overlay?
>>
>> I've upgraded portage so I know it's a version that supports sets, but
>> for some reason it's not working.
>>
>> Ideas?
> 
> Well, first off as all the kdesvn and earlier kde-4 packages were masked 
> and you had to unmask them for installation, it should be a simple matter 
> of deleting all those package.unmask entries you added to unmask them, 
> running emerge --update, and portage should take care of the details on 
> its own.  Of course, don't forget the --depclean and revdep-rebuild steps 
> afterward, cleaning up the loose ends. Given the flexibility of portage, 
> there are several other ways to do it, some of which are listed below, 
> but this might be the simplest, particularly since you should really do 
> it anyway, thus cleaning up your portage config after your testing.
> 


Duncan, as always you are indeed a help.  I do have a question, I 
removed the package.unmask entries, but I'm not seeing the kde4.1.2 
packages.  I don't run ~arch, however, so I'm assuming I"ll need to 
unmask the packages for 4.1.2 as per the documentation, correct?


-- 
Libenter homines id quod volunt credunt -- Caius Julius Caesar


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support

[gentoo-amd64] Re: Following the kde4.1 upgrade guide

[Duncan]

"Mark Haney" <mhaney@ercbroadband.org> posted
49071FA1.9050202@ercbroadband.org, excerpted below, on  Tue, 28 Oct 2008
10:20:17 -0400:

> Duncan, as always you are indeed a help.  I do have a question, I
> removed the package.unmask entries, but I'm not seeing the kde4.1.2
> packages.  I don't run ~arch, however, so I'm assuming I"ll need to
> unmask the packages for 4.1.2 as per the documentation, correct?

Yes.

FWIW, I run FEATURES=buildpkg so I always have binpkgs for what's 
installed, but otherwise I'd consider quickpkging the existing KDE before 
you upgrade, just in case something doesn't work on the upgrade.  Then 
I'd unmerge the existing kde4, so it didn't screw anything up going to 
the new version.

BTW, if you are still running kde3 as well, I strongly recommend 
USE=kdeprefix.  Unfortunately there's a ways to go in getting the 
unprefixed kde4 to stay out of the way of kde3.  People are having 
problems with kde3 apps because the config search path is the normal dirs 
(/usr/share/config and friends) before the prefix dirs 
(/usr/kde/3.5/share/config and friends), and if kde4 is installed without 
kdeprefix, it installs to the normal dirs, screwing up the config for 
kde3 packages.  This system config problem is quite apart from the user 
config issues, which are more or less solved at this point, provided you 
follow instructions (or were using separate user accounts for kde3 and 
kde4, as recommended way earlier).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: Following the kde4.1 upgrade guide

[Mark Haney]

Duncan wrote:

> 
> Yes.

Here's my problem, when I follow the documentation, I put the file in 
package.keywords, and that doesn't unmask them when I do an emerge 
--update.  At this point, I think the documentation is wrong and that 
should be placed in package.unmask, right?

> 
> FWIW, I run FEATURES=buildpkg so I always have binpkgs for what's 
> installed, but otherwise I'd consider quickpkging the existing KDE before 
> you upgrade, just in case something doesn't work on the upgrade.  Then 
> I'd unmerge the existing kde4, so it didn't screw anything up going to 
> the new version.

You know, I've never used that feature before, or in fact built any 
packages as backups.  Got any tips or link to show me the best way to 
handle it?

> 
> BTW, if you are still running kde3 as well, I strongly recommend 
> USE=kdeprefix.  Unfortunately there's a ways to go in getting the 
> unprefixed kde4 to stay out of the way of kde3.  People are having 
> problems with kde3 apps because the config search path is the normal dirs 
> (/usr/share/config and friends) before the prefix dirs 
> (/usr/kde/3.5/share/config and friends), and if kde4 is installed without 
> kdeprefix, it installs to the normal dirs, screwing up the config for 
> kde3 packages.  This system config problem is quite apart from the user 
> config issues, which are more or less solved at this point, provided you 
> follow instructions (or were using separate user accounts for kde3 and 
> kde4, as recommended way earlier).
> 

Actually, I do have 3.5.9 on this box and I've yet to go back to it now 
that 4.1.1 is on it.  However, I'd already decided to use kdeprefix 
anyway, mainly because I feel more comfortable moving through that 
upgrade path than NOT using it.



-- 
Libenter homines id quod volunt credunt -- Caius Julius Caesar


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support