[gentoo-amd64] Updates other than the masked one

[gentoo-amd64] Updates other than the masked one

[Martin Herrman]

All,

since about a week or so, the kdebase-runtime-meta package is masked,
see below. I'm quite sure that in the mean time other packages have
been updated as well. How can I install these other updates to prevent
that eventually I have to update a bunch of packages that takes me
several hours to compile? (of course, without allowing the masked
package to be installed..)

Thanx,

Martin

==========================

martindesktop ~ # emerge --update --deep --newuse --pretend world

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy
">=kde-base/kdebase-runtime-meta-4.3.4[-kdeprefix,semantic-desktop,handbook]"
have been masked.
!!! One of the following masked packages is required to complete your request:
- kde-base/kdebase-runtime-meta-4.3.4-r1 (masked by: ~amd64 keyword)

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
(dependency required by "kde-base/kdelibs-4.3.4" [ebuild])
(dependency required by "world" [argument])

martindesktop ~ #

[gentoo-amd64] Re: Updates other than the masked one

[Duncan]

Martin Herrman posted on Sun, 27 Dec 2009 08:45:50 +0100 as excerpted:

> All,
> 
> since about a week or so, the kdebase-runtime-meta package is masked,
> see below. I'm quite sure that in the mean time other packages have been
> updated as well. How can I install these other updates to prevent that
> eventually I have to update a bunch of packages that takes me several
> hours to compile? (of course, without allowing the masked package to be
> installed..)
> 
> Thanx,
> 
> Martin
> 
> ==========================
> 
> martindesktop ~ # emerge --update --deep --newuse --pretend world
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> 
> !!! All ebuilds that could satisfy
> ">=kde-base/kdebase-runtime-meta-4.3.4[-kdeprefix,semantic-
desktop,handbook]"
> have been masked.
> !!! One of the following masked packages is required to complete your
> request: - kde-base/kdebase-runtime-meta-4.3.4-r1 (masked by: ~amd64
> keyword)
> 
> For more information, see the MASKED PACKAGES section in the emerge man
> page or refer to the Gentoo Handbook. (dependency required by
> "kde-base/kdelibs-4.3.4" [ebuild]) (dependency required by "world"
> [argument])
> 
> martindesktop ~ #

Are you running standard amd64 keyword, or ~amd64?  It appears from that, 
that you'd be running amd64 (stable), because it's ~amd64 masked.

So which version of kde (or kdelibs if you only have a few kde packages, 
not most/all of the software collection) is installed?  According to the 
changelog, kde-base/kdebase-runtime-meta was only introduced for kde 
4.3.4, the package didn't exist earlier.  But kde 4.3.4 is ~amd64 
masked.  So why is a package that never existed for previous versions now 
in your world file, or a dependency of something that is, if you're not 
yet running the ~amd64 kde 4.3.4?

If you're running stable amd64 normally, but have whatever parts of kde 
4.3.4 you have installed in your package.keywords file, then you now need 
to add kde-base/kdebase-runtime-meta to it as well, as it's now required 
by kdelibs 4.3.4 (because upstream requires it, see gentoo bug #295456).

Bottom line, if you have (amd64 stable) kdelibs-4.3.3 installed, kdebase-
runtime-meta shouldn't be being pulled in, unless you're trying to 
upgrade whatever kde parts you have to 4.3.4.  If you have 
package.keyworded parts of kde 4.3.4 and have it installed, they you need 
to package.keyword kdebase-runtime-meta (and all the packages it pulls 
in), because it's now a dependency.  Either that, or downgrade back to 
4.3.3 and remove the 4.3.4 package.keyword entries you already have, if 
you aren't prepared to keyword runtime-meta and its dependencies as well.

---

Alternatively, and directly answering your question, tho it won't be 
supported and may not work so well, to get a list of @world upgrades, you 
can (temporarily) add kdebase-runtime-meta (and its dependencies) to your 
package.keywords, then do an emerge --pretend --update, and get a list.  
You can then update (emerge --oneshot package, so it doesn't put extra 
entries in your world file) the ones you want from that list, 
individually.  When you are done updating what you want, you can remove 
the temporary package.keywords, so they're masked again.

But rather than that, I'd seriously recommend either downgrading to 4.3.3 
if you want to stick with stable, or keywording the rest of your kde 
4.3.4 dependencies so all of kde is ~arch and sticking with 4.3.4.

-- 
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: Updates other than the masked one

[Martin Herrman]

On Sun, Dec 27, 2009 at 10:39 AM, Duncan <1i5t5.duncan@cox.net> wrote:

> Are you running standard amd64 keyword, or ~amd64?  It appears from that,
> that you'd be running amd64 (stable), because it's ~amd64 masked.
>
> So which version of kde (or kdelibs if you only have a few kde packages,
> not most/all of the software collection) is installed?  According to the
> changelog, kde-base/kdebase-runtime-meta was only introduced for kde
> 4.3.4, the package didn't exist earlier.  But kde 4.3.4 is ~amd64
> masked.  So why is a package that never existed for previous versions now
> in your world file, or a dependency of something that is, if you're not
> yet running the ~amd64 kde 4.3.4?
>
> If you're running stable amd64 normally, but have whatever parts of kde
> 4.3.4 you have installed in your package.keywords file, then you now need
> to add kde-base/kdebase-runtime-meta to it as well, as it's now required
> by kdelibs 4.3.4 (because upstream requires it, see gentoo bug #295456).
>
> Bottom line, if you have (amd64 stable) kdelibs-4.3.3 installed, kdebase-
> runtime-meta shouldn't be being pulled in, unless you're trying to
> upgrade whatever kde parts you have to 4.3.4.  If you have
> package.keyworded parts of kde 4.3.4 and have it installed, they you need
> to package.keyword kdebase-runtime-meta (and all the packages it pulls
> in), because it's now a dependency.  Either that, or downgrade back to
> 4.3.3 and remove the 4.3.4 package.keyword entries you already have, if
> you aren't prepared to keyword runtime-meta and its dependencies as well.
>
> ---
>
> Alternatively, and directly answering your question, tho it won't be
> supported and may not work so well, to get a list of @world upgrades, you
> can (temporarily) add kdebase-runtime-meta (and its dependencies) to your
> package.keywords, then do an emerge --pretend --update, and get a list.
> You can then update (emerge --oneshot package, so it doesn't put extra
> entries in your world file) the ones you want from that list,
> individually.  When you are done updating what you want, you can remove
> the temporary package.keywords, so they're masked again.
>
> But rather than that, I'd seriously recommend either downgrading to 4.3.3
> if you want to stick with stable, or keywording the rest of your kde
> 4.3.4 dependencies so all of kde is ~arch and sticking with 4.3.4.

Hi Duncan,

thanks for your clear explanation. Yes, I'm running stable, but have
installed KDE4 by adding a bunch of packages to the unmask list. I
didn't realise that with new packages for KDE4, I obviously had to add
them to the list.. So I added runtime-meta today and upgrading to the
latest packages was smooth as usual again :-)

Thanks!

Martin

[gentoo-amd64] Re: Updates other than the masked one

[Duncan]

Martin Herrman posted on Mon, 28 Dec 2009 21:08:14 +0100 as excerpted:

> thanks for your clear explanation. Yes, I'm running stable, but have
> installed KDE4 by adding a bunch of packages to the unmask list. I
> didn't realise that with new packages for KDE4, I obviously had to add
> them to the list.. So I added runtime-meta today and upgrading to the
> latest packages was smooth as usual again :-)

Cool! =:^)

You didn't mention whether you read the bug I linked or not, but it gives 
the reason behind the addition.  Upstream kde is considering it "core" 
now, and packages may begin to use any of the included runtime 
functionality without warning.  There's already (Gentoo-specific) bugs 
appearing that they're having to deal with, because Gentoo wasn't 
requiring it and thus certain assumed present functionality was missing.

As usual, individual Gentoo users can use package.provided to avoid 
having to install some of the new packages if they only use individual 
kde apps, but they do so in the knowledge that they are short-circuiting 
a dependency mechanism and may be causing breakage to their own setup.  
(One such example is amarok, which now requires certain kdebase-runtime 
functionality for its lastfm support.  Apparently, that functionality was 
broken for some users that used it, who filed bugs, with this being the 
resolution.)

-- 
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: Updates other than the masked one

[Martin Herrman]

On Tue, Dec 29, 2009 at 6:30 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>
> Cool! =:^)
>
> You didn't mention whether you read the bug I linked or not, but it gives
> the reason behind the addition.  Upstream kde is considering it "core"
> now, and packages may begin to use any of the included runtime
> functionality without warning.  There's already (Gentoo-specific) bugs
> appearing that they're having to deal with, because Gentoo wasn't
> requiring it and thus certain assumed present functionality was missing.
>
> As usual, individual Gentoo users can use package.provided to avoid
> having to install some of the new packages if they only use individual
> kde apps, but they do so in the knowledge that they are short-circuiting
> a dependency mechanism and may be causing breakage to their own setup.
> (One such example is amarok, which now requires certain kdebase-runtime
> functionality for its lastfm support.  Apparently, that functionality was
> broken for some users that used it, who filed bugs, with this being the
> resolution.)

Hi Duncan,

actually, I had already read it before I wrote the original posting. I
just didn't realise that I could 'safely' unmask the package (because
I already had chosen to run the unstable KDE4.3 release).

I like the concept of Gentoo, the power it gives to me, the safe
bleeding-edge apps and the ease in which I can run my own custom build
kernel. But on the other hand: I just need a working desktop and in
98% of the cases I don't want to dive into all the details to get
things working. This seems to be a contradiction, I should have been
an Ubuntu user, but that's not true :-D Now and then I apply some
custom USE-flags, but I stick to the default install as much as I can
so I'm not the one to discover bugs.

Regards,

Martin

[gentoo-amd64] Re: Updates other than the masked one

[Duncan]

Martin Herrman posted on Wed, 30 Dec 2009 21:51:23 +0100 as excerpted:

> actually, I had already read [the bug] before I wrote the original
> posting. I just didn't realise that I could 'safely' unmask the package
> (because I already had chosen to run the unstable KDE4.3 release).

Good, you put the "'safely'" in quotation marks.  Given that you already 
chose to run the unstable kde4.3, it's no /additional/ risk, and actually 
is by far less trouble than otherwise, but you obviously realize the 
(measured) level of risk you take going with unstable kde4.3 or you'd 
have not had to use those quotation marks around /safely/.

=:^/

> I like the concept of Gentoo, the power it gives to me, the safe
> bleeding-edge apps and the ease in which I can run my own custom build
> kernel. But on the other hand: I just need a working desktop and in 98%
> of the cases I don't want to dive into all the details to get things
> working. This seems to be a contradiction, I should have been an Ubuntu
> user, but that's not true :-D Now and then I apply some custom
> USE-flags, but I stick to the default install as much as I can so I'm
> not the one to discover bugs.

... but you didn't quote "safe" there. =:^\  Maybe that's because it's a 
bother when you already quoted it above, but anyway...


Really, truth be known, from my perspective the whole kde thing is 
screwed up right now -- and not by Gentoo, but upstream kde.  
Unfortunately there's a kde conundrum. kde4 is still under /very/ heavy 
development, and still has significant enough bugs that to call it 
"stable" in /any/ form remains a bit of a stretch.  Honestly, despite kde-
upstream's claims about kde4.2, even kde4.3 is only now reaching late 
beta, 4.2 was early beta or late alpha, 4.1 was early alpha, and 4.0 was 
only a conference level technology preview.  By many predictions 
(including but not limited to my own), 4.4 should finally be release 
candidate level, no real show-stoppers but still somewhat rough around 
the edges.  Following that trend, 4.5 should finally be more or less 
ready for normal/ordinary use -- full release.  (Well, there's a possible 
exception for kmail, which will be switching to akonadi with 4.5, but 
they are said and one hopes it's true, to be taking their time and 
getting it right, the reason they didn't try for 4.4.  Perhaps that's the 
"less" of "more or less", above.)

Given that, in a sane world, kde 3 would remain supported and with us for 
another year, thru 2010 at least, since 4.4 is scheduled for February, 
4.5 for August, and there should be at least a few months of overlap to 
give people time to sanely make the change before the end of support for 
the previous stable version.

Unfortunately, by that metric, kde no longer belongs to a sane world 
(which of course implies serious questions about the sanity of those who 
still use it... like me and obviously you, but be that as it may...), 
since it dropped kde3 support with the release of 3.5.10 and 4.2.0.  And 
of course the qt3 upon which kde3 is built was EOLed before that (tho 
I've never checked the specific timing on that end, only taken kde's word 
for it).

Unfortunately, but those are the facts on the ground as distributions and 
ultimately us users must deal with them.  Simplest terms, that leaves us 
users stuck between a rock and a hard place.  We have three choices:

(1) Dump kde entirely for something "sane".

While this might be the "sane" choice, many users don't find it 
particularly viable, for whatever reason.

(2) Follow kde3/qt3 off into the sunset, at least until kde4 is found 
suitably stable (for various definitions of "stable").  That's likely 
another year if we're lucky for traditional "stable" distribution users, 
including gentoo stable arch users.  For those like me who enjoy testing 
betas, the current 4.3 is about right.  (I switched with 4.2.4, but it 
was **EXTREMELY** difficult, over a hundred hours of /extra/ work, 
hacking scripts to replace broken functionality, etc, in /addition/ to 
the usual and expected upgrade hassles.  Few have the time even if they 
had the motivation and skills for such an undertaking.).  Obviously, the 
real bleeding edge folks, or those who are generally content with the 
default/common functionality, could have (and many did) changed earlier, 
while those between the beta/unstable tester folks like me and the stable 
folks, will find a point in the middle to switch.
 
(3) Undertake a "forced" upgrade to kde4, likely before one would have 
otherwise done so.

Actually, I did this, as I had been /trying/ (and failing) to do the 4.x 
upgrade since before 4.0, and would have definitely waited until at least 
4.3, had kde3 not already been marching off into the sunset. (I like to 
give myself plenty of time, and get the conversion done well before the 
drop-dead date, which I did, tho at enormous cost in time and hassle.)

Meanwhile, and this is the point of the message, for those choosing #3, 
because kde4 /is/ under such intense continued development, and because 
it /does/ have such serious bugs remaining, once one is on kde4, the 
latest stable upstream kde4, thus for Gentoo users, ~arch keyworded kde4, 
since it takes some time to stabilize on Gentoo, is likely going to be 
less trouble than stable kde4, because more bugs are fixed upstream, and 
the major kde4 integration issues are already dealt with at the 
gentoo/kde level, so what remains is rather minor integration bugs for 
~arch, as the measured risk for getting the DEFINITELY more bugfixed 
latest from kde upstream.

Given all that and being the beta tester type I am, I'd probably actually 
be running the kde-4.3.8x kde-4.4 betas from the kde overlay, except that 
I have another major project I'm working on ATM -- getting my Acer Aspire 
One netbook up and running on Gentoo.  But that's close, and I may or may 
not get to the 4.4-rcs before the 4.4.0 general release.

(FWIW on the AA1, I have the completed image done on my main machine, 
copied to USB stick, copied from there to the AA1's drive, and tested 
booting.  But I screwed up the grub install somehow and thus still have 
to boot from the grub on the USB stick, but to the installation on the 
hard drive, so I have that to figure out still, and then I still have X 
and kde to configure/customize, networking to get running, etc.  A few 
hours more work, probably, but it's /almost/ there!  I'm hoping to have 
it running tomorrow, before the new year starts, at LEAST the grub bit 
worked out, and hopefully xorg, with the syntouch config for the evdev 
driver and the extra keys.  If I'm still running the default kde4.3 as 
the new year comes in, but have the grub issue traced and resolved, and
xorg/keyboard-extra-keys/syntouch configured, I'll be happy.  =:^)

(But what I'm /really/ looking forward to for the netbook is the
plasma-netbook aka plasma-newspaper layout, tho that's kde4.5 material
I think.)

-- 
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