upgrade of media-libs/jpeg-7 breaks nxclient. Rebuild of nxclient causes downgrade to jpeg-6b-r8 Reproducible: Always
No. nxclient-3.3.0.3.ebuild: || ( media-libs/jpeg-compat <media-libs/jpeg-7 ) nxclient-3.3.0.6.ebuild: || ( media-libs/jpeg-compat <media-libs/jpeg-7 ) Install jpeg-compat instead.
Then why does rebuild of nxclient cause downgrade to 6b instead of pulling in jpeg-compat?
It doesn't. # emerge -pv nxclient [ebuild N ] media-libs/jpeg-compat-6b 0 kB [ebuild N ] net-misc/nxclient-3.3.0.6 4,469 kB # emerge -pv =jpeg-7* nxclient [ebuild R ] media-libs/jpeg-7 0 kB [ebuild N ] media-libs/jpeg-compat-6b 0 kB [ebuild N ] net-misc/nxclient-3.3.0.6 4,469 kB Paste outputs of prev. commands and emerge --info.
It does with paludis $ sudo paludis -ip nxclient Building target list... Building dependency list...paludis@1252243031: [WARNING dep_list.downgrade] In thread ID '28967': ... In program paludis -ip nxclient: ... When performing install action from command line: ... When executing install task: ... When building dependency list: ... When adding PackageDepSpec 'net-misc/nxclient': ... When adding package 'net-misc/nxclient-3.3.0.6:0::gentoo': ... When adding run dependencies as pre dependencies: ... When using already installed package to resolve dependencies: ... When adding PackageDepSpec '<media-libs/jpeg-7': ... Downgrade to 'media-libs/jpeg-6b-r8:0::gentoo' from 'media-libs/jpeg-7:0::installed' forced These packages will be installed: * media-libs/jpeg [D 7 -> 6b-r8] Reasons: *net-misc/nxclient-3.3.0.6:0::gentoo, app-text/ghostscript-gpl-8.70-r1:0::installed, 4 more build_options: -optional_tests split strip * net-misc/nxclient [N 3.3.0.6] <target> build_options: -optional_tests "X11/VNC/NXServer client (remote desktops over low-bandwidth links)" Total: 2 packages (1 new, 1 downgrade) Checking for possible errors...... * No unread news items found
Highly unlikely that it's Paludis getting it wrong here... What does paludis -q jpeg-compat show?
$ paludis -q jpeg-compat * media-libs/jpeg-compat layman: (6b (in ::multilib))X {:0} gentoo: 6b(~)* {:0} Homepage: http://www.ijg.org/ Description: Library to load, handle and manipulate images in the JPEG format (transition package) Herds: graphics Maintainers: graphics@gentoo.org Use flags: Build Options: -optional_tests split strip
Install jpeg-compat then, and Paludis will use it instead. Paludis is correctly seeing that you have jpeg and not jpeg-compat installed, and is thus using jpeg to satisfy the || ( ) dependency. If you have both installed, Paludis will take the leftmost instead.
I know what to do now but that does not solve the problem for others. The sequence of events is as follows: 1. jpeg-7 is installed as part of an overall update of world 2. reconcilo runs and rebuilds 24 packages that were dependent on jpeg-6b 3. note: nxclient is not rebuild by reconcilio 4. nxclient fails to run because a dependent library is missing. 5. An attempted paludis -i nxclient tries to downgrade jpeg to 6b-r8 instead of installing jpeg-compat. I don't know what is at fault but clearly this is not what should happen.
Paludis is behaving correctly based upon the information that it is given. It's up to you to decide whether you'd rather keep jpeg at version 6 or install the compat package. Paludis can't read your mind, and it isn't told by the ebuild how to solve the problem, so it picks the solution that works best in the majority of cases that look like the one in question.
I don't think the problem is in Paludis. The problem is a general QC issue and should be referred to whoever is in charge of QC for Gentoo. The only issue in question with Paludis is why nxclient didn't qualify for a rebuild by reconcilio as it was clearly broken and why Paludis did spot nxclient as a blocker for the installation of jpeg-7. It seems that as portage becomes more automated regarding blockers and such, ebuilds are being built that are neither functionally compatible nor tested with Paludis leading to user issues that result in needless wasting of developer time.
(In reply to comment #10) > I don't think the problem is in Paludis. The problem is a general QC issue and > should be referred to whoever is in charge of QC for Gentoo. No. Paludis is not a Gentoo project at all. Portage is. You shouldn't be reporting bugs from Paludis system before trying the same with Portage...
(In reply to comment #9) > Paludis is behaving correctly based upon the information that it is given. No. It shouldn't be preferring a downgrade instead of alternative depend if available.
Paludis is in the tree. Most of the packages in the tree are not gentoo developed packages. Paludis is an alternative package manager and as such should be tested like any other package in the tree. If gentoo does not wish to support alternative package managers they should not be listed as such and should not be in the tree. I don't believe this is the case. If Gentoo is going to support alternative package managers then ebuilds should be tested on them.
(In reply to comment #13) > If Gentoo is going to support alternative package managers then ebuilds > should be tested on them. I don't see anything wrong with the dependency in nxclient: || ( media-libs/jpeg-compat <media-libs/jpeg-7 ) And the solution for the upgrade path was given in comment #7. > Paludis is in the tree. Most of the packages in the tree are not gentoo > developed packages. If you think that this is a Paludis bug (I'm not sure if it is), then you should report it to their upstream at <http://trac.pioto.org/paludis/>. This kind of problems can't be fixed in any reasonable way at the distro level. (That's the same for Paludis as for other packages' upstreams.)
I don't know if it is a paludis bug. I may be but it could also be an ebuild bug. Upstream says that they are doing what the ebuild specifies. I'm not so sure but in any case the list of steps in comment #8 is not how I would like to see things work. There was not even an elog in jpeg-7 mentioning jpeg-compat or even an ewarning to run revdep-rebuild or reconcilio. Frustrating users is not the way forward.
(In reply to comment #12) > (In reply to comment #9) > > Paludis is behaving correctly based upon the information that it is given. > > No. It shouldn't be preferring a downgrade instead of alternative depend if > available. I can understand why you'd jump to that conclusion based upon a naive look at a single particular case without considering the big picture. However, when you bear in mind that sometimes Gentoo does force downgrades, and that a good number of packages are mutually exclusive, the situation is not so straight forward, and taking the downgrade is the less dangerous solution.
(In reply to comment #15) > I don't know if it is a paludis bug. I may be but it could also be an ebuild > bug. Upstream says that they are doing what the ebuild specifies. No, the ebuild specifies to use jpeg-compat first, and then old jpeg as alternative if jpeg-compat for some reason isn't available and that's how it's working here with portage (see Comment #3, it was a short test, can't tell if there's more pkgs involved in calculating that depgraph.) > There was not even an elog in jpeg-7 mentioning jpeg-compat or even an > ewarning to run revdep-rebuild or reconcilio. The need for revdep-rebuild has partly been removed/fixed in Portage 2.2_rc* (still masked) by preserved-libs feature. In this case, it would have kept the libjpeg.so.62 when installing jpeg-7 and it would have instructed you to run "emerge @preserved-rebuild" after that. In short: It's the package managers job to handle this, not a job for the ebuild to print messages...
