| Summary: | Version drift in KDE split ebuilds - a support nightmare waiting to happen! | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Karl Günter Wünsch <kgw> |
| Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | major | CC: | craig |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | output of emerge -uDpv --debug @world 2>&1 | ||
|
Description
Karl Günter Wünsch
2008-09-29 13:42:42 UTC
(In reply to comment #0) > The big argument against the monolithic ebuilds is the large set of > applications and libraries installed, but if you installed all 15 you at least > knew that you had a complete set of the specific installed version and emerge > would be able to tell you which version was current and which was installed, > even if you chose to downgrade and not run the latest version. What is difference here between emerge -uDav kdentwork:3.5 and emerge -uDav kdentwork-meta:3.5? If anything, the new sets should make this even more clear. > With the split ebuilds you now have to shift through 300+ version numbers and > because you don't step each and every one of them you have no way of knowing > which version belongs to which older or newer version. If you mean that visually it was easier to track 15 ebuilds than 200+, I'll have to agree, but what prevents you from using the tools we provide? emerge -uDav works as well with 3 ebuilds as it does with 300. > There have been numerous > times when due to external needs an upgrade to a newer version of KDE simply > had to be postponed - something quite impossible now. > Worst of all: This behaviour is now enforced for the users of KDE3 as well, how > would you update a system that's kept running and the time window for an update > is too small (due to useage hours) to unmerge the monotlithic builds and merge > the split ones instead (10+ hours compile time for the monolithic builds)? I'm sorry, but I think this argument is bogus. Granted, that installing kdenetwork using the meta ebuild should be slightly slower than using the monolithic ebuild, but with the meta you can install only the apps you want (which might make it faster than installing the mono) and you can update a few deps at a time - you can update 4 packages now, 3 in a few hours and the remaining 5 tomorrow. So although the initial install might take a bit longer, even though it might be possible to update a few deps of a meta per time window where the update of the monolithic wouldn't be possible, after you switch to the split ebuilds, the update process should be less painful. "but what prevents you from using the tools we provide?" It is much easier preventing 15 packages of KDE to update - or can you do that with a set? (In reply to comment #2) > "but what prevents you from using the tools we provide?" > It is much easier preventing 15 packages of KDE to update - or can you do that > with a set? Yes, you can. emerge -uDav @kdenetwork (a set from the kde-testing overlay) will update all packages that are part of the kdenetwork set. We don't currently have individual sets for kde-3.5, but I've add a kde-3.5 set to that overlay - http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob_plain;f=sets/kde-3.5;hb=master (In reply to comment #3) > (In reply to comment #2) > > "but what prevents you from using the tools we provide?" > > It is much easier preventing 15 packages of KDE to update - or can you do that > > with a set? > Yes, you can. > emerge -uDav @kdenetwork (a set from the kde-testing overlay) will update all > packages that are part of the kdenetwork set. Why is it that I feel misunderstood? I may have to prevent such a set from updating! Not update one selectively but quite the opposite! Masking 300 packages is not what I would call useful! Thanks to the version jump on kdelibs without similar jumps in the other packages, I can't even emerge --update amarok -- or anything else that uses kdelibs:
WanderingFigment portage # emerge -pu xine-lib amarok
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] dev-lang/ruby-1.8.6_p287-r1 [1.8.6_p287]
[ebuild U ] media-sound/amarok-1.4.10-r1 [1.4.9.1-r1]
[ebuild U ] kde-base/kdelibs-3.5.10 [3.5.9-r4] USE="doc*"
[blocks B ] kde-base/kdenetwork ("kde-base/kdenetwork" is blocking kde-base/kdelibs-3.5.10)
[blocks B ] kde-base/kdeartwork ("kde-base/kdeartwork" is blocking kde-base/kdelibs-3.5.10)
[blocks B ] kde-base/kdepim ("kde-base/kdepim" is blocking kde-base/kdelibs-3.5.10)
[blocks B ] kde-base/kdemultimedia ("kde-base/kdemultimedia" is blocking kde-base/kdelibs-3.5.10)
[blocks B ] kde-base/kdeadmin ("kde-base/kdeadmin" is blocking kde-base/kdelibs-3.5.10)
[blocks B ] kde-base/kdebase ("kde-base/kdebase" is blocking kde-base/kdelibs-3.5.10)
[blocks B ] kde-base/kdegraphics ("kde-base/kdegraphics" is blocking kde-base/kdelibs-3.5.10)
[blocks B ] kde-base/kdewebdev ("kde-base/kdewebdev" is blocking kde-base/kdelibs-3.5.10)
[blocks B ] kde-base/kdegames ("kde-base/kdegames" is blocking kde-base/kdelibs-3.5.10)
[blocks B ] kde-base/kdeaddons ("kde-base/kdeaddons" is blocking kde-base/kdelibs-3.5.10)
[blocks B ] kde-base/kdeutils ("kde-base/kdeutils" is blocking kde-base/kdelibs-3.5.10)
-- but from long pre-Gentoo experience building kde, I know that I could rebuild the libs without really affecting anything else, when it's only a patchlevel jump. What's going on?
Please post the output of emerge -uDpv --debug @world Created attachment 167596 [details]
output of emerge -uDpv --debug @world 2>&1
As requested, the rather lengthy output of emerge etc.
From the --debug output I see a single block that has nothing to do with KDE and 1 fetch restriction related to a Java package:
[blocks b ] =dev-texlive/texlive-basic-2007* ("=dev-texlive/texlive-basic-2007*" is blocking app-text/texlive-core-2008)
It also seems like emerge -uDav @world should update your system:
Total: 151 packages (139 upgrades, 12 new), Size of downloads: 527,628 kB
Fetch Restriction: 1 package (1 unsatisfied)
Conflict: 1 block
(In reply to comment #8) Thanks, but I have absolutely no intention of emerging world before I edit it and clear out a lot of junk. I see no dependency on texlive anywhere that would explain why kdelibs gets blocked. What I noticed in the output was that all the 3.5.9 packages require kdelibs [exactly] 3.5.9, NOT =>3.5.9 =<3.5.999, which according to KDE practice it should be. Is that why it's blocking? How are the rest of the .10 packages coming? I'm going to close this bug as there's nothing we can do and there's actually no request for us to do anything. (In reply to comment #9) > (In reply to comment #8) > > Thanks, but I have absolutely no intention of emerging world before I edit it > and clear out a lot of junk. I see no dependency on texlive anywhere that > would explain why kdelibs gets blocked. > > What I noticed in the output was that all the 3.5.9 packages require kdelibs > [exactly] 3.5.9, NOT =>3.5.9 =<3.5.999, which according to KDE practice it > should be. Is that why it's blocking? How are the rest of the .10 packages > coming? What you're seeing is that kde-3.5.10 is keyworded and so Portage tries to upgrade your system to the latest visible version. If you had 3.5.10 masked, you wouldn't have those issues. |
