So, based on that I need to change my USE flag for qt-core-4.5.2 to [-qt3support], okay. I go into /etc/portage/package.use/monolithic to this:

x11-libs/qt-core -qt3support (actually I just comment out the line, but in effect I'm removing qt3support from qt-core).

When I do so and I re-run the update I get this:

> emerge: there are no ebuilds built with USE flags to satisfy "~x11-libs/qt-core-4.5.2[glib,qt3support,-debug]". > !!! One of the following packages is required to complete your request: > - x11-libs/qt-core-4.5.2 (Change USE: +qt3support) > (dependency required by "x11-libs/qt-gui-4.5.2-r2" [ebuild]) > (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild]) > (dependency required by "kdelibs" [argument])

So, which is it? It can't be both ways, and to be honest, trying to figure out which file needs which USE flag on what day is getting kinda silly.

On Donnerstag 30 Juli 2009, Mark Haney wrote: > I'm beginning to wonder if Gentoo is right for me any more. I swear, > the dependencies and USE flag changes are killing me. Here's my latest > fun: > > I'm trying to upgrade kdelibs (to 4.2.4-r4) and I get this: > > octavian ~ # ACCEPT_KEYWORDS="~amd64" emerge -uav kdelib > > > > These are the packages that would be merged, in order: > > > > Calculating dependencies... done! > > > > emerge: there are no ebuilds built with USE flags to satisfy > > "~x11-libs/qt-core-4.5.2[-debug,-qt3support]". !!! One of the following > > packages is required to complete your request: - x11-libs/qt-core-4.5.2 > > (Change USE: -qt3support) > > (dependency required by "x11-libs/qt-opengl-4.5.2" [ebuild]) > > (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild]) > > (dependency required by "kdelibs" [argument]) > > So, based on that I need to change my USE flag for qt-core-4.5.2 to > [-qt3support], okay. I go into /etc/portage/package.use/monolithic to this: > > x11-libs/qt-core -qt3support (actually I just comment out the line, but > in effect I'm removing qt3support from qt-core). > > When I do so and I re-run the update I get this: > > emerge: there are no ebuilds built with USE flags to satisfy > > "~x11-libs/qt-core-4.5.2[glib,qt3support,-debug]". !!! One of the > > following packages is required to complete your request: - > > x11-libs/qt-core-4.5.2 (Change USE: +qt3support) > > (dependency required by "x11-libs/qt-gui-4.5.2-r2" [ebuild]) > > (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild]) > > (dependency required by "kdelibs" [argument]) > > So, which is it? It can't be both ways, and to be honest, trying to > figure out which file needs which USE flag on what day is getting kinda > silly.

try syncing again. And masking qt3support fro qt-core is not enough. Either enable it globally or disable it globally - or add all your qt packages to package.use.

On 7/30/09, Volker Armin Hemmann <volkerarmin [at] googlemail> wrote: > On Donnerstag 30 Juli 2009, Mark Haney wrote: >> I'm beginning to wonder if Gentoo is right for me any more. I swear, >> the dependencies and USE flag changes are killing me. Here's my latest >> fun: >> >> I'm trying to upgrade kdelibs (to 4.2.4-r4) and I get this: >> > octavian ~ # ACCEPT_KEYWORDS="~amd64" emerge -uav kdelib >> > >> > These are the packages that would be merged, in order: >> > >> > Calculating dependencies... done! >> > >> > emerge: there are no ebuilds built with USE flags to satisfy >> > "~x11-libs/qt-core-4.5.2[-debug,-qt3support]". !!! One of the following >> > packages is required to complete your request: - x11-libs/qt-core-4.5.2 >> > (Change USE: -qt3support) >> > (dependency required by "x11-libs/qt-opengl-4.5.2" [ebuild]) >> > (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild]) >> > (dependency required by "kdelibs" [argument]) >> >> So, based on that I need to change my USE flag for qt-core-4.5.2 to >> [-qt3support], okay. I go into /etc/portage/package.use/monolithic to >> this: >> >> x11-libs/qt-core -qt3support (actually I just comment out the line, but >> in effect I'm removing qt3support from qt-core). >> >> When I do so and I re-run the update I get this: >> > emerge: there are no ebuilds built with USE flags to satisfy >> > "~x11-libs/qt-core-4.5.2[glib,qt3support,-debug]". !!! One of the >> > following packages is required to complete your request: - >> > x11-libs/qt-core-4.5.2 (Change USE: +qt3support) >> > (dependency required by "x11-libs/qt-gui-4.5.2-r2" [ebuild]) >> > (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild]) >> > (dependency required by "kdelibs" [argument]) >> >> So, which is it? It can't be both ways, and to be honest, trying to >> figure out which file needs which USE flag on what day is getting kinda >> silly. > > try syncing again. And masking qt3support fro qt-core is not enough. Either > enable it globally or disable it globally - or add all your qt packages to > package.use.

I don't think there is a need to sync. qt-core, qt-gui,qt-sql, and qt-opengl just must all have either qt3support on or off, mixing them with different USE flag settings won't work. Also, kde4-base.eclass seems to require qt3support on, so there isn't much choice about configuration here ... OP just hasn't gotten the whole mile, yet.

But you are right: OP should just enable qt3support in /etc/make.conf -- or arduously list out at least the four qt-* packages with qt3support enabled under his choice of files/dirs under /etc/portage if he is a micromanagement-masochist.

About his pondering on whether Gentoo is right for him and about Gentoo having been more and more work to maintain recently -- I wholeheartedly agree. I just haven't found anything better, yet.

On Thu, Jul 30, 2009 at 21:45, Mark Haney<mhaney [at] ercbroadband> wrote: > I'm beginning to wonder if Gentoo is right for me any more. I swear, > the dependencies and USE flag changes are killing me. Here's my latest fun: > > I'm trying to upgrade kdelibs (to 4.2.4-r4) and I get this: > >> octavian ~ # ACCEPT_KEYWORDS="~amd64" emerge -uav kdelibs >> >> These are the packages that would be merged, in order: >> >> Calculating dependencies... done! >> >> emerge: there are no ebuilds built with USE flags to satisfy "~x11-libs/qt-core-4.5.2[-debug,-qt3support]". >> !!! One of the following packages is required to complete your request: >> - x11-libs/qt-core-4.5.2 (Change USE: -qt3support) >> (dependency required by "x11-libs/qt-opengl-4.5.2" [ebuild]) >> (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild]) >> (dependency required by "kdelibs" [argument]) >> > > So, based on that I need to change my USE flag for qt-core-4.5.2 to > [-qt3support], okay. I go into /etc/portage/package.use/monolithic to this: > > x11-libs/qt-core -qt3support (actually I just comment out the line, but > in effect I'm removing qt3support from qt-core). > > When I do so and I re-run the update I get this: > >> emerge: there are no ebuilds built with USE flags to satisfy "~x11-libs/qt-core-4.5.2[glib,qt3support,-debug]". >> !!! One of the following packages is required to complete your request: >> - x11-libs/qt-core-4.5.2 (Change USE: +qt3support) >> (dependency required by "x11-libs/qt-gui-4.5.2-r2" [ebuild]) >> (dependency required by "kde-base/kdelibs-4.2.4-r4" [ebuild]) >> (dependency required by "kdelibs" [argument]) > > So, which is it? It can't be both ways, and to be honest, trying to > figure out which file needs which USE flag on what day is getting kinda > silly. > > -- > Interdum feror cupidine partium magnarum Europae vincendarum > > Mark Haney > Sr. Systems Administrator > ERC Broadband > (828) 350-2415 > >

> I don't think there is a need to sync. qt-core, qt-gui,qt-sql, and > qt-opengl just must all have either qt3support on or off, mixing them > with different USE flag settings won't work.

Exactly. Remember, it's basically a single package, upstream. So it's best to treat all split packages from it as a single unit, same C(XX) FLAGS/LDFLAGS, same USE flags, for the whole package.

Also note that it doesn't work well to have the different parts be different upstream versions (IOW, the -rX number doesn't have to match, because that's Gentoo-only, but the upstream version, everything before the -rX number, should match). If one is upgraded, all the others should be as well, to keep them all in sync. Doing otherwise WILL mean problems. For those routinely doing --deep upgrades, that won't be a problem as they'll all become available together and the --upgrade --deep will ensure they're all upgraded together. Those not using --deep, however, will have to ensure that the versions stay synced, tho AFAIK the packages now use blocking of other versions to help ensure that remains the case.

FWIW, I don't pay attention to whether something's listed as a global USE flag or local, I decide which I want as the system default, and put that in my make.conf USE flags. The only entries I have in package.use are then those where I want something other than the system default, for some reason. In this case, qt3support was a no-brainer for me since I knew kde was going to require it, so qt3support went in make.conf as turned on.

BTW, I also strongly prefer to decide how I want my USE flags set, and put that in make.conf and for changes for individual packages, packages.use, regardless of whether they're turned on or not. Thus, there's a decent number of -flag entries in my USE flags. That way, I don't have to worry about profile changes or the defaults on individual packages changing, since I have the policy set system-wide to what I want, regardless of what the package or profile defaults are. That saved me a lot of trouble when I switched from the desktop to the no-multilib profile, for instance, and to a lessor extent, saves me trouble / whenever/ I upgrade profiles (when I upgraded to 2008.0, for instance).

It also would have saved a lot of trouble for the OP here, since Alex pointed out that the reason this is coming up is that the qt package defaults changed.

> But you are right: OP should just enable qt3support in /etc/make.conf -- > or arduously list out at least the four qt-* packages with qt3support > enabled under his choice of files/dirs under /etc/portage if he is a > micromanagement-masochist.

=:^) It should be obvious from the above which I'd choose, make.conf, tho as I said, I actually prefer to set -flags in there as well, which might be called micromanagement too. package.use is only for packages that I want flags that don't fit my chosen system defaults.

For example, I don't run aRTs and have the flag turned off system-wide, but have it turned on in package.use for kdelibs:3.5, as I have arts- plugins-xine installed to generate video thumbnails, and it needs the arts flag turned on in kdelibs. (Rant: I don't know why I have to have aRTs installed to get video thumbnails, as I said, I don't actually use aRTs, but that's the way the package is setup. <shrug>)

> About his pondering on whether Gentoo is right for him and about Gentoo > having been more and more work to maintain recently -- I wholeheartedly > agree. I just haven't found anything better, yet.

I don't agree. Gentoo's about the same as it has been, even lower work if anything for me recently. But then again, I believe I use better management techniques than many users do -- at least better for me. And as what was working for others seems to be causing issues now, perhaps they'd be better for them, as well. <shrug>

As I said, I prefer deciding what I want for USE flags and setting that globally, either hard on or hard off, and only change that for specific packages. And I always do --upgrade --deep --newuse, preferably syncing and running upgrades at least twice a week, so nothing on my system gets too stale -- including all the deep dependencies. I'm ALWAYS at the latest unmasked (to ~arch since that's what I use) version, which I think helps even if it does mean a bit faster churn on deep dependencies than I'd otherwise have. And, upgrading twice a week means I normally don't have many packages to upgrade (big kde upgrades being a huge exception, since that's /always/ well over 100 individual packages), so if something goes wrong, I find out about it right away, and it's pretty easy to figure out which package was the culprit.

After every upgrade, I run revdep-rebuild (of course with --pretend firt, or with --ask) and rebuild what's necessary (which is FAR less with as- needed in LDFLAGS than it would be otherwise, but OTOH, the --upgrade -- deep means more frequent library upgrades, thus triggering revdep- rebuilds in some cases). The --deep --newuse on my upgrades by default definitely helps here too, as it helps keep the dependencies sorted out that would otherwise get screwed up due to USE flag changes not being reflected in what's actually installed.

I also run emerge --depclean (--ask or --pretend first) every time after the upgrade, and then another revdep-rebuild if I removed anything, just to be sure it didn't leave any dependency holes.

Of course I also do the etc-update, whether portage tells me to or not, just to be sure.

I expect I've saved myself a LOT of trouble over the years, due to a few basics like the above sysadmin policies. With a modern multi-core CPU and at least a couple gigs RAM, Gentoo really isn't all that hard to keep up, provided you are serious enough about sysadminning to learn how to play it smart, not rough. But that last bit is critical. Gentoo provides the tools and manages the ebuilds, plus a good amount of documentation. But it's not about hand-holding. Gentoo expects users to be able to read docs and learn how to take best advantage of the tools provided. If you're not ready to do that, Gentoo's really not the distribution for you. I read that Ubuntu's pretty decent at making things brainless. That may well be a better choice for those who aren't serious enough about their sysadminning to learn what the provided tools are and how to use them to best effect.

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

> > About his pondering on whether Gentoo is right for him and about Gentoo > having been more and more work to maintain recently -- I wholeheartedly > agree. I just haven't found anything better, yet. >

It hasn't been more and more work for me, but then I try to maintain a minimalist system, which means I avoid these bloated, do-it-all-for- everyone monstrosities like KDE or Gnome. A simple window manager is good enough for my purposes.

But what is meant by "better?" If you seek to eliminate the work of administration, that is, as I understand it, not the goal of Gentoo. In order to customize a system to ones liking, one has to to understand thoroughly how the system functions. Gentoo facilitates customization but it does not eliminate the need to understand -- and understanding can involve a lot of work. If the user is not willing to research and explore, then the user should indeed be advised to seek elsewhere.

IMO, for one who seeks control and the ability to customize, there is nothing better than Gentoo. The only alternative is to build and maintain a system independently, in the manner of Linux From Scratch.

But I've been down that road. Until recently, I used to compile all my own packages and completely administer my own personal "distribution." It was a fair amount of work, but with the proper organization and a lot of ambition ambition, it was quite feasible. However, certain developments in the Open Source world eventually served to dampen my enthusiasm. The most significant of these developments was the splitting of the X Window package from one into literally dozens of individual programs. With this change -- as well as several others that I won't mention -- the work load slowly became more and more unbearable, and I realized that I would not be able to continue doing it alone. After considering a lot of possibilities, I discovered Gentoo and realized that my needs could be once again be fulfilled without the excessive burden.

It should also be considered that perhaps the upstream developers are making things more difficult. Many new packages that have been released seem to break everything that depends on them. For example, a new jpeg library, version 7, was released recently (which has not yet made it into Gentoo) that will require a rebuild of every program that processes images, and this includes the extensive GTK package as it uses libjpeg for its pixbuffer loader. Another example is the new gcc compiler, version 4.4.x. I have noticed that many packages will fail to compile with the new version of gcc and this necessitates that the previous version, 4.3.3, be also kept installed on the system. Lastly, do I need to mention the fiasco with the update of the xcb package for X Window? Once again, a single change has broken everything that has gone before. It has to be admitted that these upstream developers are not making life any easier for the distribution maintainers.

But that's the nature of progress, I suppose. Fortunately, Gentoo can give the serious user a set of tools to better deal with these inevitable changes.

> It should also be considered that perhaps the upstream developers are > making things more difficult.

No kidding!

> Many new packages that have been released > seem to break everything that depends on them. For example, a new jpeg > library, version 7, was released recently (which has not yet made it > into Gentoo) that will require a rebuild of every program that processes > images, and this includes the extensive GTK package as it uses libjpeg > for its pixbuffer loader.

Thanks for the warning! I hadn't read anything about that one yet.

> Another example is the new gcc compiler, > version 4.4.x. I have noticed that many packages will fail to compile > with the new version of gcc and this necessitates that the previous > version, 4.3.3, be also kept installed on the system.

I routinely install any new gcc version before it's unmasked to ~arch. As such, I'm used to dealing with packages that won't yet compile with the new version, searching Gentoo and other bug systems for patches, etc. Due to the hard work of many even before a public release (Gentoo toolchain folks and adventurous users try rebuilding with the rcs, and some routinely test weekly snapshots during development. Debian as well tests, and many of our patches to make existing packages compile with new gcc versions come from there. Fedora Rawhide, similarly, and I've actually worked with SuSE devs on testing a patch for an upstream package (pan) that I'm involved with upstream, myself.

But as we're talking about Gentoo tools making it easier, slotted gcc and gcc-config definitely belong on that list, as they SURE make it easier testing various new compilers, and switching back to the old one when necessary. The process would be SERIOUSLY harder without this sort of Gentoo tools and slotted gcc.

> Lastly, do I need > to mention the fiasco with the update of the xcb package for X Window? > Once again, a single change has broken everything that has gone before.

That one actually had FAR less effect on me than I expected. From the Gentoo/X project discussion of things (in the tracking bug and on the desktop list, IIRC, the former discovered by reading the latter), I expected something on the size of the expat fiasco, but with virtually all X apps needing recompiled. Never-the-less, I upgraded (again, while it was masked, actually, I grabbed it while it was still on the X overlay, IIRC), and things weren't anywhere NEAR that bad. I think I had a half dozen, maybe a dozen packages to upgrade, instead of the couple hundred or so I expected.

But I expect what saved me on that was having -as-needed in LDFLAGS. It really DOES make a HUGE difference. The goal is eventually to make that the Gentoo default, but there's still a lot of packages that don't work with it, tho most of them have been patched or at least have filter- ldflags called for it, so it doesn't hit users as much as it used to. Flame-eyes is the expert on -as-needed (it was his blog I discovered it on), and his tinder-box has really weeded out a bunch of issues both there and elsewhere. That alone is a huge benefit to Gentoo, even if he didn't contribute huge amounts of fixes and technical help for other devs, which he does. (Unfortunately, he reminds me a lot of my father and sister. All three are extremely bright, genius level or close to it, all three workaholics -- they see so much to be done and so few able to do it, and try to do it all themselves! And all three have the health problems that go with the territory. All three of them have had to learn to deliberately slow down and pace themselves, after they got sick and nearly died from simply trying to do to much.)

For those who wish to try it, here's mine:

LDFLAGS="-Wl,-z,now,--as-needed,-O1,--hash-style=gnu,--sort-common"

The "now" bit people will likely want to avoid. The others should be useful, tho there has been discussion about making them Gentoo default, and part of them may be default by now (they weren't when I added them, tho).

There are some others I've seen as well, but I don't know enough about them to use them. For the ones above (covered in the ld manpage except for -Wl, in the gcc manpage, see below):

-Wl is actually a gcc option, telling it to pass what follows to the linker. See the gcc manpage for this one.

-z,now (as opposed to -z,lazy) tells the linker to force all links to be resolved at initial program load. This takes a bit more time /at/ initial load, but when an application would otherwise pause for additional library functions to load, it now doesn't have to. It's thus a trade-off. It also has a couple other effects. Memory use will be slightly higher tho not too much, so I'd say it's probably best not to do unless you've 2 gigs RAM or more. But the two effects I use it for are: (1) If a library or function from a library can't load, I'd prefer to see the error at startup, not later, when the program tries to load that bit. This ensures that. (2) There are certain somewhat narrow security benefits. I won't attempt to explain them here and they are rather narrow, but given I have 8 gigs RAM so that's not an issue, and I considered the other aspects slightly positive, with no visible downside, I thought it worth it.

I've had this enabled for years, now, with no issues /except/ with the ati/radeon drivers when xorg split into modular packages. I had to turn off -z,now for the xf86-ati-radeon package (using the /etc/portage/env/ method to do it for just that package) for awhile as a result. They eventually patched the package to filter -z,now, and I'm not sure if it has been resolved upstream by now or not, but with the package patched to filter it, I don't have to worry about it now.

--as-needed tells the linker to only tag libraries it actually uses as NEEDED, not everything on the include line, or indirect dependencies like the libraries other libraries it is using use. The result is that unnecessary linkages are avoided, and FAR fewer rebuilds need done when a library changes as a result.

I've had this enabled for quite some time now without many issues, probably as a result of flame-eyes' testing. This one should therefore be pretty trouble-free now, and has a HUGE upside, but it does still have the potential to cause occasional issues on new or obscure packages. But I really DO think the upside is worth it!

-O1 is much like the gcc -O optimization functions, but there's only the single -O1 level, for linking. This one's newer, but I've had no problems with it at all, probably because it's commonly enabled and thus well tested.

Gentoo's former default for hash was --hash-style=both, but hash- style=gnu along with -O1 and sort-common were proposed as new defaults. I'm not sure if they made it or not, but in any case, this one shouldn't be an issue on Linux at all, and I've certainly not had issues at all. The other alternative and linker default (before Gentoo's default kicks in) is hash-style=sysv.

--sort-common sorts symbols by their alignment size, >=16,8,4,2,1 bytes. This packs them tighter than they'd be be otherwise, due to alignment constraint issues, thus making for slightly smaller binaries.

I think the --as-needed will make the most difference, and I'm SURE it has saved me a LOT of pain, even with the xcb issue alone. I absolutely believe it's worthwhile, and that the pain saved will MORE than make up for any occasional issues one /might/ run into with new or obscure individual packages. Note that -Wl is actually a gcc option, telling it to pass what follows to the linker. Thus, the format for /just/ as- needed would be:

LDFLAGS="-Wl,--as-needed"

> It has to be admitted that these upstream developers are not making life > any easier for the distribution maintainers.

> But that's the nature of progress, I suppose. Fortunately, Gentoo can > give the serious user a set of tools to better deal with these > inevitable changes.

Agreed.

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

> I expect I've saved myself a LOT of trouble over the years, due to a few > basics like the above sysadmin policies. With a modern multi-core CPU > and at least a couple gigs RAM, Gentoo really isn't all that hard to keep > up, provided you are serious enough about sysadminning to learn how to > play it smart, not rough. But that last bit is critical. Gentoo > provides the tools and manages the ebuilds, plus a good amount of > documentation. But it's not about hand-holding. Gentoo expects users to > be able to read docs and learn how to take best advantage of the tools > provided. If you're not ready to do that, Gentoo's really not the > distribution for you. I read that Ubuntu's pretty decent at making > things brainless. That may well be a better choice for those who aren't > serious enough about their sysadminning to learn what the provided tools > are and how to use them to best effect. >

Here's my take on this, since I am OP. For the last year or two, I've had, more and more, to go straight to ~arch for 'stable' packages. This isn't so much about KDE4, which I /expected/ to be funky when it was released, it's virtually everything else. Unlike some people, or most, if I read the list right, are already running ~amd64 on their systems.

I am not.

And I do not want to. What's the point in having 'stable' when virtually no packages are marked as such any more? I've been running qt4.5 for nearly a year now. Isn't it about bloody time it gets marked stable? Hell, IIRC, KDE3.5.10 isn't even marked stable (or wasn't last time I looked).

I make the comment about it being right for me because I have been getting the feeling Gentoo is becoming 'Debian v2.0' by just leaving everything useful in ~arch (or testing in Debian's case).

If it is STABLE, mark it as such. Don't sit here and tell me, 'Oh just run ~amd64 widget, it's stable'.

When I started with Gentoo in 2005/6, I could emerge -uD world and know it'll pull in the latest stable packages and be done with it. Now, I have to watch because some packages aren't, some might need a downgrade of a package, which I have to mask so it doesn't get downgraded, ad infinitum.

To me, the distro is just feeling kinda sloppy on the back end. No, I'm not looking for a 'Ubuntu' experience. That distro gives me heartburn. But, geez, I do expect packages to be moved from testing to stable slightly more often than never. I'm not trying to be overly critical here, but the way things are going, it's getting /harder/ to maintain a STABLE system now than it used to be.

And, FWIW, on topic, having qt3support globally makes no difference. I still have a thousand bleeding hoops to jump through to fix all the asinine blocks and dependencies.

Something is fishy, those blocks are meant to tell you you're trying to mix qt versions which is *not* supported.

There are a few things you can do to get rid of this once and for all: - make sure your /var/lib/portage/world has no references to qt (4) - make sure your emerge commands won't try to fetch only part of qt

> > > Many new packages that have been released > > seem to break everything that depends on them. For example, a new jpeg > > library, version 7, was released recently (which has not yet made it > > into Gentoo) that will require a rebuild of every program that processes > > images, and this includes the extensive GTK package as it uses libjpeg > > for its pixbuffer loader. > > Thanks for the warning! I hadn't read anything about that one yet. >

FWIW, I need to continue this comment.

Since I process a lot of images, libjpeg is very important to me. The new jpeg-7 now includes arithmetic encoding which can produce smaller compressed file sizes and there are also some changes to the scaling and quality features. Unlike most Open Source packages, which are updated quite frequently (too frequently?), jpeg-7 is the first new release since 1998.

Rather than wait for Gentoo to create the ebuilds for the new jpeg-7, I decided to compile it myself and then list it in packages.provided. In addition, the old jpeg-6 shared objects were kept, but all the include files and static libraries for linking would refer to the new jpeg-7. In this way, any update of a package that depends on libjpeg would be linked with the new libraries, but any existing package that still needs jpeg-6 could be left untouched. I don't like to have to re-compile everything at once. When the time comes to update a package the new libraries will be available but until then the old libraries will suffice. (Gentoo is flexible enough to nicely accomodate this.)

However, after emerging a new GTK+, which automatically then became linked to the new jpeg-7 libraries, I noticed a severe problem. Jpeg images viewed using programs that depend on GTK+ -- and there are a lot of them -- were strangely blurred and out of focus. Doing some searching, I found this thread that explains the problem:

The issue is with the new scaling methods in jpeg-7. Programs such as firefox and many others process images through GTK+ facilities, and GTK+ needs to be patched before it can utilize the new jpeg-7. AFAIK, the GTK+ people do not even yet know about this issue. Also, unless I am mistaken, any patch that accommodates jpeg-7 will no longer function with jpeg-6.

So there ends my nice, neat plan to have both jpeg-7 and jpeg-6 together serving my system. The situation also illustrates how unanticipated problems can easily be injected into this loose but wonderful conglomeration known as Open Source software.

You missed one. qt-script-4.5.1 is still installed, and it's blocking the others. As I said, all bits of qt4 must be the same version, so to get 4.5.2, you can't have 4.5.1 installed. Not a bit of it.

I believe portage could resolve it if all parts were 4.5.1 and it could upgrade them all to 4.5.2 at once, but with mixed versions, or with one bit of 4.5.1 and trying to pull the others, because it tries to install the latest available, it doesn't work because that blocks and portage isn't smart enough to know how to /safely/ resolve it. (Portage defaults to just spitting out the blockers and letting you resolve it, if it can't be SURE it can do so safely.)

Once you have all bits of qt4 either on the same version, or all removed, portage should be able to resolve things on its own.

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

On Fri, Jul 31, 2009 at 17:03, Mark Haney<mhaney [at] ercbroadband> wrote: > But I'm not. The packages I am trying to upgrade are the only packages > installed on my system. I should uninstall packages that don't exist on > my system to make this work?

Not true, you had some Us in your output, like: >> [ebuild U ] x11-libs/qt-script-4.5.2 [4.5.1] USE="iconv -debug -pch (-custom-cxxflags%)" 0 kB So perhaps there are (were) others installed there and portage complained about mixing them :)

> Here's my take on this, since I am OP. For the last year or two, I've > had, more and more, to go straight to ~arch for 'stable' packages. This > isn't so much about KDE4, which I /expected/ to be funky when it was > released, it's virtually everything else. Unlike some people, or most, > if I read the list right, are already running ~amd64 on their systems. > > I am not. > > And I do not want to. What's the point in having 'stable' when > virtually no packages are marked as such any more? I've been running > qt4.5 for nearly a year now. Isn't it about bloody time it gets marked > stable? Hell, IIRC, KDE3.5.10 isn't even marked stable (or wasn't last > time I looked).

Note that while Gentoo does provide the tools to mix stable and ~arch for those who wish to try, it's not well tested or supported. All stable is supposed to be well tested, and all ~arch should be tested working at least on the Gentoo package maintainer's machines with all ~arch, but mixing the two is asking for trouble.

Meanwhile, one of the issues with stable (which people like me parse as stale with a "b" added... hmm... I like that description, I think I'll keep using it! =:^) is that it takes people to test it that are willing to stay as far back as stale is in general, so they're testing a stale install not an ~arch install, but who are also willing to test candidates for stale, ensure they work, and report them as working.

You say you have a big package.keywords file right now. But have you been reporting as working packages as you install them, so that the Gentoo/amd64 folks know they are working? (Maybe you are, I don't know, and I'm not saying you have to, but somebody has to, and those like me that want ~arch systems aren't going to be able to test with stale, and those who never install ~arch packages at all aren't going to be testing since they stick to stale, so the only ones left to test and report working are those who are mostly stale but do install the occasional not- yet-stale package.

> I make the comment about it being right for me because I have been > getting the feeling Gentoo is becoming 'Debian v2.0' by just leaving > everything useful in ~arch (or testing in Debian's case).

I've never run Debian, and prefer not to run stale anyway, so can't honestly say, there. But what I can say is that in all honesty, at least for me, if Gentoo/amd64 dropped stable all together (as is the case with a couple of the obscure archs, labeled 'experimental') it would only be beneficial to me, as that would be more testing and developer power for the ~arch I'm actually running.

But I'm not selfish enough to wish that on the folks running stable. I'm just not interested in something that stale, is all, so it doesn't matter to me one way or the other.

> If it is STABLE, mark it as such. Don't sit here and tell me, 'Oh just > run ~amd64 widget, it's stable'.

They DO mark it as such, when they KNOW it's stale. But they don't KNOW it's stale, unless it has been reasonably tested on an otherwise stale system, and the people willing to do that testing and actually report the results aren't so easy to come by, so it's taking longer to know it's stale.

> When I started with Gentoo in 2005/6, I could emerge -uD world and know > it'll pull in the latest stable packages and be done with it. Now, I > have to watch because some packages aren't, some might need a downgrade > of a package, which I have to mask so it doesn't get downgraded, ad > infinitum.

Well, as I said, mixed stale and unstale isn't well tested or supported. But if it's marked stale and is removed, forcing a downgrade, there's a reason for it. OTOH if you package.keyworded as specific version, and it goes away, then yes, portage will suggest a downgrade. But that could only happen because it wasn't considered stale in the first place, and as an ~arch package with newer ones available, it can be removed.

> To me, the distro is just feeling kinda sloppy on the back end. No, I'm > not looking for a 'Ubuntu' experience. That distro gives me heartburn. > But, geez, I do expect packages to be moved from testing to stable > slightly more often than never. I'm not trying to be overly critical > here, but the way things are going, it's getting /harder/ to maintain a > STABLE system now than it used to be.

It may indeed be getting harder to maintain a stale system. I wouldn't know. But what I can say is what I said above, the only way the packages are going to move to stale is if people on stale test them and say they work on stale.

> And, FWIW, on topic, having qt3support globally makes no difference. I > still have a thousand bleeding hoops to jump through to fix all the > asinine blocks and dependencies.

It's really not that bad. As revealed in a different post, you had parts of and old qt4 blocking the newer version. As I said, trying to do multiple versions of the qt4 components doesn't work. It has to be all one version. Again as I said, once it's all one version, if you do --update --deep, the system should pretty much take care of its own updates. But it can't do that safely with split versions, and it'll have difficulty doing it if you don't run your updates with --deep, as well.

So you're breaking at least one and possibly two rules (in addition to running an unsupported partially ~arch and partially stale arch system), trying to have multiple qt4 versions, and possibly, trying to update without using --deep, thus only making more trouble for yourself.

If it's that far behind, why not run ~arch? A number of users have reported that full ~arch has actually been more stable for them than partially stale, partially ~arch. Either you want stale or you don't, and it doesn't appear you're satisfied with it, so...

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

On Fri, Jul 31, 2009 at 8:44 AM, Frank Peters<frank.peters [at] comcast> wrote: > Since I process a lot of images, libjpeg is very important to me. The new > jpeg-7 now includes arithmetic encoding which can produce smaller compressed > file sizes and there are also some changes to the scaling and quality features. > Unlike most Open Source packages, which are updated quite frequently (too > frequently?), jpeg-7 is the first new release since 1998. > > Rather than wait for Gentoo to create the ebuilds for the new jpeg-7, I decided > to compile it myself and then list it in packages.provided. In addition, > the old jpeg-6 shared objects were kept, but all the include files and > static libraries for linking would refer to the new jpeg-7. In this way, > any update of a package that depends on libjpeg would be linked with the > new libraries, but any existing package that still needs jpeg-6 could be > left untouched. I don't like to have to re-compile everything at once. When > the time comes to update a package the new libraries will be available but until > then the old libraries will suffice. (Gentoo is flexible enough to nicely > accomodate this.) > > However, after emerging a new GTK+, which automatically then became linked > to the new jpeg-7 libraries, I noticed a severe problem. Jpeg images viewed > using programs that depend on GTK+ -- and there are a lot of them -- were > strangely blurred and out of focus. Doing some searching, I found this > thread that explains the problem: > > http://bbs.archlinux.org/viewtopic.php?id=75529> > The issue is with the new scaling methods in jpeg-7. Programs such as firefox > and many others process images through GTK+ facilities, and GTK+ needs to be > patched before it can utilize the new jpeg-7. AFAIK, the GTK+ people do not > even yet know about this issue. Also, unless I am mistaken, any patch that > accommodates jpeg-7 will no longer function with jpeg-6. > > So there ends my nice, neat plan to have both jpeg-7 and jpeg-6 together > serving my system. The situation also illustrates how unanticipated problems > can easily be injected into this loose but wonderful conglomeration known > as Open Source software.

FWIW the newly-released gtk+ 2.16.6 of a coupel days ago still has the problem with jpeg-7, but there was a patch in the gtk bugzilla that fixed the problem for me:

On Wed, Sep 2, 2009 at 9:12 AM, Paul Hartman<paul.hartman+gentoo [at] gmail> wrote: > FWIW the newly-released gtk+ 2.16.6 of a coupel days ago still has the > problem with jpeg-7, but there was a patch in the gtk bugzilla that > fixed the problem for me:

> > Also, there was at least one package that needed to be rebuilt despite > the fact revdep-rebuild didn't think so: media-libs/sdl-image > > I'm curious to know if there are any more out there hiding... >

Just for the record, did anyone else not get the OP to this reply? I'm curious as to the problem the OP was having.

On Wed, Sep 2, 2009 at 10:29 AM, Mark Haney<mhaney [at] ercbroadband> wrote: > Paul Hartman wrote: > >> >> Also, there was at least one package that needed to be rebuilt despite >> the fact revdep-rebuild didn't think so: media-libs/sdl-image >> >> I'm curious to know if there are any more out there hiding... >> > > Just for the record, did anyone else not get the OP to this reply? I'm > curious as to the problem the OP was having.

On 09/02/2009 06:29 PM, Mark Haney wrote: > Paul Hartman wrote: > >> >> Also, there was at least one package that needed to be rebuilt despite >> the fact revdep-rebuild didn't think so: media-libs/sdl-image >> >> I'm curious to know if there are any more out there hiding... >> > > Just for the record, did anyone else not get the OP to this reply? I'm > curious as to the problem the OP was having.

Paul Hartman wrote: > On Wed, Sep 2, 2009 at 10:29 AM, Mark Haney<mhaney [at] ercbroadband> wrote: >> Paul Hartman wrote: >> >>> Also, there was at least one package that needed to be rebuilt despite >>> the fact revdep-rebuild didn't think so: media-libs/sdl-image >>> >>> I'm curious to know if there are any more out there hiding... >>> >> Just for the record, did anyone else not get the OP to this reply? I'm >> curious as to the problem the OP was having. > > Original of this branch of the thread was by Frank Peters on July 31. >

Ah. Okay, /that's/ why I don't have the thread in my inbox. I archive off anything older than a month. Thanks for clearing that up, I was afraid our mail server was acting up.