From http://fedoraproject.org/wiki/Extras_2fFC4Status:
"gpredict (i386, x86_64) - gnome-vfs-devel - buildreq couldn't be installed"
Yes, why is that anyways? I tried to hunt down a reason in the mailing list archives but couldn't find one.
On Tue, 5 Apr 2005, Ignacio Vazquez-Abrams wrote:
From http://fedoraproject.org/wiki/Extras_2fFC4Status:
"gpredict (i386, x86_64) - gnome-vfs-devel - buildreq couldn't be installed"
Yes, why is that anyways? I tried to hunt down a reason in the mailing list archives but couldn't find one.
It should be, but remember that programs that require gnome 1.x libraries are "bad" and ones that use gnome 2.x libraries are "good" :) Anything using 1.x should be ported to 2.x.
Dan
On Tue, 2005-04-05 at 08:09 -0400, Dan Williams wrote:
...but remember that programs that require gnome 1.x libraries are "bad" and ones that use gnome 2.x libraries are "good" :) Anything using 1.x should be ported to 2.x.
No argument here, I'm just curious as to why this particular package disappeared.
On Tue, 2005-04-05 at 08:16 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-04-05 at 08:09 -0400, Dan Williams wrote:
...but remember that programs that require gnome 1.x libraries are "bad" and ones that use gnome 2.x libraries are "good" :) Anything using 1.x should be ported to 2.x.
No argument here, I'm just curious as to why this particular package disappeared.
If nothing in Core uses a package then the package is not included. It might end up in Extras.
On Tue, 2005-04-05 at 09:09 -0400, Sean Middleditch wrote:
If nothing in Core uses a package then the package is not included. It might end up in Extras.
/me waits patiently for gtk+ to drop out and have plenty of people scream bloody murder
On Tue, 2005-04-05 at 14:57 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-04-05 at 09:09 -0400, Sean Middleditch wrote:
If nothing in Core uses a package then the package is not included. It might end up in Extras.
/me waits patiently for gtk+ to drop out and have plenty of people scream bloody murder
what's left that deps on gtk+?
xmms just got dropped out? is it just gnucash that's left?
-sv
On Tue, 2005-04-05 at 15:01 -0400, seth vidal wrote:
On Tue, 2005-04-05 at 14:57 -0400, Ignacio Vazquez-Abrams wrote:
/me waits patiently for gtk+ to drop out and have plenty of people scream bloody murder
what's left that deps on gtk+?
xmms just got dropped out? is it just gnucash that's left?
Yep, that's it.
On Tue, 2005-04-05 at 15:03 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-04-05 at 15:01 -0400, seth vidal wrote:
On Tue, 2005-04-05 at 14:57 -0400, Ignacio Vazquez-Abrams wrote:
/me waits patiently for gtk+ to drop out and have plenty of people scream bloody murder
what's left that deps on gtk+?
xmms just got dropped out? is it just gnucash that's left?
Yep, that's it.
so when you say 'plenty of people' you meant to say 'the 5 people using gnucash' :-D
/me hides
-sv
On Tue, 2005-04-05 at 15:08 -0400, seth vidal wrote:
On Tue, 2005-04-05 at 15:03 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-04-05 at 15:01 -0400, seth vidal wrote:
On Tue, 2005-04-05 at 14:57 -0400, Ignacio Vazquez-Abrams wrote:
/me waits patiently for gtk+ to drop out and have plenty of people scream bloody murder
what's left that deps on gtk+?
xmms just got dropped out? is it just gnucash that's left?
Yep, that's it.
so when you say 'plenty of people' you meant to say 'the 5 people using gnucash' :-D
/me hides
Heh. And every single user of every single app in every single non-Core repo that still needs it.
On Tue, 2005-04-05 at 15:14 -0400, seth vidal wrote:
What else deps on gtk+ 1.X?
Things in extras?
A couple, yes.
is gtk+ even being maintained upstream anymore? Seems like a good candidate for going to extras then, doesn't it?
It seems like a good candidate even if it _is_ being maintained upstream, seeing as how Core is down to 2 dep packages.
On Tue, 2005-04-05 at 15:25 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-04-05 at 15:14 -0400, seth vidal wrote:
What else deps on gtk+ 1.X?
Things in extras?
A couple, yes.
is gtk+ even being maintained upstream anymore? Seems like a good candidate for going to extras then, doesn't it?
It seems like a good candidate even if it _is_ being maintained upstream, seeing as how Core is down to 2 dep packages.
agreed.
-sv
seth vidal (skvidal@phy.duke.edu) said:
is gtk+ even being maintained upstream anymore? Seems like a good candidate for going to extras then, doesn't it?
It seems like a good candidate even if it _is_ being maintained upstream, seeing as how Core is down to 2 dep packages.
agreed.
Disagree. The mantra here is 'apps before libraries'.
If the apps stand by themselves as parts of core, the library deps stand by themselves. If they don't, the libraries don't.
In essence, apps should be moved because of duplication of functionality/not required functionality. Not because of toolkit alone.
Otherwise, you'd get into the situation were "we moved this out because it used gtk1. Now it's ported to gtk2. Let's move it back!" Which is just plain weird.
Bill
Disagree. The mantra here is 'apps before libraries'.
If the apps stand by themselves as parts of core, the library deps stand by themselves. If they don't, the libraries don't.
In essence, apps should be moved because of duplication of functionality/not required functionality. Not because of toolkit alone.
Otherwise, you'd get into the situation were "we moved this out because it used gtk1. Now it's ported to gtk2. Let's move it back!" Which is just plain weird.
Good points.
-sv
On Tue, Apr 05, 2005 at 03:14:55PM -0400, seth vidal wrote:
What else deps on gtk+ 1.X?
Things in extras? is gtk+ even being maintained upstream anymore? Seems like a good candidate for going to extras then, doesn't it?
Since I run one of my machines without gtk+ (which makes for a good test) I know that there are things in extras like easytag (since Extras hasn't moved to the quite-stable-but-still-officially development 1.99.3 version), plus outside things like mplayer.
The other, slightly nastier problem: Several packages allow one to build with either gtk+ or gtk2. In Core, we're building with gtk2, but these packages have to BuildRequire: gtk+-devel, which pulls in the rest of the gtk+ stuff, in order to compile. This is because the various auto* scripts pull in gtk+ macros. I *think* there are some packages still like this in Core; I know I've run into it in the last couple months, and have gotten used to pulling in gtk+ in order to build, then removing it, when I want to rebuild a package.
There are also a couple other packages that incorrectly still BuildRequire various gtk+ things even after having moved to gtk2, but the gtk+ things are no longer needed. w3m is a case of this; it just moved to gtk2, but still BuildRequires imlib-devel instead of imlib2-devel. (I guess imlib2-devel is needed, haven't tested trying to build without it installed, but it definitely builds with imlib2-devel but not imlib-devel if I change the spec file.)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153773
John Thacker
On Tue, Apr 05, 2005 at 03:42:03PM -0400, John Thacker wrote:
The other, slightly nastier problem: Several packages allow one to build with either gtk+ or gtk2. In Core, we're building with gtk2, but these packages have to BuildRequire: gtk+-devel, which pulls in the rest of the gtk+ stuff, in order to compile. This is because the various auto* scripts pull in gtk+ macros. I *think* there are some packages still like this in Core; I know I've run into it in the last couple months, and have gotten used to pulling in gtk+ in order to build, then removing it, when I want to rebuild a package.
Ah, remembered one of the examples. xcdroast won't build without gtk+ installed, even though it only links against gtk2. That's because it can be built against either, and the use of various auto* macros.
Of course, xcdroast also has this big honking error which was fixed in FC3 but the patch applied in FC3 is still left out of the devel package: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134334
I rebuilt it myself after doing the trivial work necessary to apply the patch; that's why I found that it requires gtk+ installed. (The actual RPM BuildRequire is on gdk-pixbuf-devel, which yoinks the rest in.)
John Thacker
On Tue, Apr 05, 2005 at 03:42:03PM -0400, John Thacker wrote:
On Tue, Apr 05, 2005 at 03:14:55PM -0400, seth vidal wrote:
What else deps on gtk+ 1.X?
The other, slightly nastier problem: Several packages allow one to build with either gtk+ or gtk2. In Core, we're building with gtk2, but these packages have to BuildRequire: gtk+-devel, which pulls in the rest of the gtk+ stuff, in order to compile. This is because the various auto* scripts pull in gtk+ macros. I *think* there are some packages still like this in Core; I know I've run into it in the last couple months, and have gotten used to pulling in gtk+ in order to build, then removing it, when I want to rebuild a package.
Is this just pkg-config stuff? That type of stuff can be fixed and submitted upstream pretty easily. If it's other auto* problems, I'd have to see it to know how easy it would be. In any case, if you send me a few packages to look at, I'll make a start on doing something productive about it.
-Toshio
On Tue, Apr 05, 2005 at 03:15:57PM -0700, Toshio Kuratomi wrote:
Is this just pkg-config stuff? That type of stuff can be fixed and submitted upstream pretty easily. If it's other auto* problems, I'd have to see it to know how easy it would be. In any case, if you send me a few packages to look at, I'll make a start on doing something productive about it.
Take a look at xcdroast. It can be set to use either gtk+ or gtk2 (and we build for gtk2), but fails building if it doesn't find gtk+ (well, really glib1), trying to run a macro.
John Thacker
On Tue, 2005-04-05 at 19:35 -0400, John Thacker wrote:
On Tue, Apr 05, 2005 at 03:15:57PM -0700, Toshio Kuratomi wrote:
Is this just pkg-config stuff? That type of stuff can be fixed and submitted upstream pretty easily. If it's other auto* problems, I'd have to see it to know how easy it would be. In any case, if you send me a few packages to look at, I'll make a start on doing something productive about it.
Take a look at xcdroast. It can be set to use either gtk+ or gtk2 (and we build for gtk2), but fails building if it doesn't find gtk+ (well, really glib1), trying to run a macro.
It looks like things are both more complex and not so problematic. The configure.in uses AM_PATH_GLIB/GTK/GDK_PIXBUF which requires the -devel packages from gtk1 to be used. However, the configure script doesn't require them at all. As long as we don't need to touch the Makefile.am or configure.in and regenerate the Makefile's we're fine without gtk1. (Just tested this in mach so I know this part works.)
If we have to make changes to configure.in or Makefile.am's, however, we'll also need to modify the configure.in script. One solution is to just patch out the checks for the gtk1 stack. They're in a small, contained section of the configure.in and could be patched out easily when changes are made to the configure.in/Makefile.am's.
The other solution which might stand a chance to go upstream is to patch the build code to use pkgconfig instead of the AM_PATH_G* macros. This way would allow the continued use of GTK1 when available without needing the gtk1 -devel packages installed to regenerate configure/Makefile.
The problem is that only the later gtk-1.2 series has pkgconfig files (CVS seems to be telling me 1.2.9) whereas xcdroast currently has a minimum requirement of 1.2.3. So upstream has to be convinced that requiring a newer version of gtk1 is ok. Still, 1.2.9 was released in 2001 so there's been quite a bit of time for people to have upgraded.
I don't know how applicable this analysis is to other packages which can compile against either gtk1 or gtk2, but it doesn't seem to be a very difficult problem to tackle.
-Toshio
On Tue, 05 Apr 2005 15:14:55 -0400, seth vidal wrote:
What else deps on gtk+ 1.X?
You can't drop GTK1 unless you want to break every single Loki Setup out there.
Unless you consider that users should be able to associate a message like:
setup: error while loading shared libraries: libgtk-1.2.so.0 not found
(which is only shown on the console) with the magic command to fix it.
I don't think that's the usability aesthetic we want on Linux ...
thanks -mike
You can't drop GTK1 unless you want to break every single Loki Setup out there.
Unless you consider that users should be able to associate a message like:
setup: error while loading shared libraries: libgtk-1.2.so.0 not found
(which is only shown on the console) with the magic command to fix it.
I don't think that's the usability aesthetic we want on Linux ...
By that argument we can never drop any library, ever b/c SOMETHING might depend on it.
-sv
Hi,
Unless you consider that users should be able to associate a message like:
setup: error while loading shared libraries: libgtk-1.2.so.0 not found
By that argument we can never drop any library, ever b/c SOMETHING might depend on it.
Correct.
Wouldn't there be a way of either reverse engineering the Loki loader to see what (if anything) it does special or adding a compat- library in?
While I completely agree with Seth's argument (I've used it plenty of times myself), losing the Loki loader would mean losing quite a lot of games which rely on the Loki loader.
TTFN
Paul
On Tue, 05 Apr 2005 18:36:04 -0400, seth vidal wrote:
By that argument we can never drop any library, ever b/c SOMETHING might depend on it.
There are two ways to look at this:
Firstly, I could say: not at all! You have to figure out the cost vs benefits on a case by case basis. GTK1 is very widespread, lots of games and commercial programs require it, and it's not a very large library. So the cost of kicking it out is high, but the benefit is low.
Or, I could say: yes, you're exactly right. It means you can't drop any library that programs could depend on. That is operating systems for you. Are you building an operating system, or merely a random snapshot of bits that work together today but might not tomorrow?
Now, I want to see Linux - and Fedora Core - be operating systems. I want to see lots of people building their software upon Free APIs, and I think we need to compete with Windows and MacOSX to get there. So I'd lean towards the second view.
Right now though it's impractical because distros ship such a huge amount of stuff, and there's no clarity or policy behind what's supported and what isn't. Except on RHEL where they say that the LSB libraries and the GNOME stack are supported, and nothing else is. Maybe Fedora should look at adopting similar policies.
thanks -mike
On Wed, Apr 06, 2005 at 03:30:51PM +0100, Mike Hearn wrote:
Or, I could say: yes, you're exactly right. It means you can't drop any library that programs could depend on. That is operating systems for you. Are you building an operating system, or merely a random snapshot of bits that work together today but might not tomorrow?
FC always includes all the libraries that programs it ships depend on. Are we saying that we can't drop any library that any program, no matter how old, no matter how unmaintained depends on?
With Free Software you can at least pick up the pieces and port or patch, but it's a nearly unsurmountable problem with non-Free programs. It's a debate that RedHat, Fedora, and Linux in general has had for a long time. How much to compromise things in order to accomodate non-Free software?
It's fair to say that backwards compatibility is *the* feature of Microsoft OSes. They spend a ridiculous amount of effort in order to assure that all sorts of broken old programs work on their newer systems, even putting in single-app-specific hacks when necessary for large enough applications. Now I'm not saying that you're arguing for going that far, but people who like Linux because they like Free Software are not enthused about bending over backwards to keep the non-Free stuff working.
John Thacker
On Thu, 07 Apr 2005 11:57:37 -0400, John Thacker wrote:
Now I'm not saying that you're arguing for going that far, but people who like Linux because they like Free Software are not enthused about bending over backwards to keep the non-Free stuff working.
Well, speaking as somebody who has spent far too much time writing new code and hacks to work around incompatible changes in lower parts of the system, I have to say your attitude that backwards compatibility only matters for proprietary software is a little grating.
Open source software isn't written by pixies you know - volunteers have to spend their evenings and weekends making changes which don't actually improve anything, they just work around changes made elsewhere. This is quite depressing work, at least for me. Sometimes it just doesn't get done. Take a look at njamd (not just another malloc debugger) some time.
From the description and documentation it looks _really_ cool, but I was
never able to try it because the code is riddled with constructs that GCC no longer compiles, for instance using __FUNCTION__ as a macro. I could have installed an old GCC I guess, or I could have gone through and tried to fix the source. In fact I did for a while, until it became clear that the problems ran deeper than just that, at which point I gave up.
Now, Microsoft understands that backwards compatibility is not a "feature" so much as a hard requirement of the product. It doesn't matter how cool Longhorn is, or how secure, or how fast, if when it comes out it doesn't run peoples programs. That's why they bend over backwards: because they want to sell lots of copies, and that means lots of people have got to (a) want and (b) be able to buy it. If word gets out that Longhorn breaks your programs, that'd be a marketing/PR disaster for them especially given their corporate customers. Look at the fuss caused just by Service Pack 2 for a taste of what that'd be like.
thanks -mike
On Thu, Apr 07, 2005 at 11:57:37AM -0400, John Thacker wrote:
FC always includes all the libraries that programs it ships depend on. Are we saying that we can't drop any library that any program, no matter how old, no matter how unmaintained depends on?
No, what he's saying is that not all libs are created equal: some are more equal than others.
In other works, some libs are part of the platform. Being part of said platform (and gtk+ *was* part of it), it means there's an unwritten contract between the developers of the distribution and the developers of 3rd party software (be they open source or proprietary, it doesn't matter), that people can _depend_ on them being around. And when you depend on something, you pretty much *expect* that support to be there. Forever. Windows did it, and it serve them well.
Particularly, in this case it costs us *very little* -- just some space. This is not a crazy proposition. Technologically, space increases exponentially, so the cost associated with the support for backwards compatibility decreases quite fast. There's too much at stake (mind share, trust, etc.) to justify the trivial cost in space.
On Thu, Apr 07, 2005 at 05:11:32PM -0400, Dimitrie O. Paun wrote:
In other works, some libs are part of the platform. Being part of said platform (and gtk+ *was* part of it), it means there's an unwritten contract between the developers of the distribution and the developers of 3rd party software (be they open source or proprietary, it doesn't matter), that people can _depend_ on them being around. And when you depend on something, you pretty much *expect* that support to be there. Forever. Windows did it, and it serve them well.
And when nothing in Core requires it, what's wrong with moving it to Extras? It's still available; it's still built. Anyone who uses the packaging system as they're meant to would have no problems pulling it in to satisfy dependencies. It would still be around, just not installed unless someone needs it. (Just as it would if it lived on in Core.)
As mentioned before, I have a strong bias against the 4 year old gtk+, and I consider applications that still use it fundamentally broken. I hope that's not coloring my views too much, but what's wrong with moving 20 or so GNOME 1.4 and gtk+1.2 (and related) packages over to Extras once gnucash is ported, and nothing in Core depends on them?
John Thacker
On Thu, Apr 07, 2005 at 05:43:14PM -0400, John Thacker wrote:
And when nothing in Core requires it, what's wrong with moving it to Extras?
Because it's no longer easily/immediately available. And nowadays it doesn't much matter if things are or aren't possible, but rather if they are easily or not accessible. More often then not, if someting is not working right out of the gate, it's not available for all intents and purposes.
Look, this guy I worked with once came up with this idea of an "Engine". It was a rather mystical thing, but any problem that we came up was somehow magically solved by the "Engine". Any diagram had an arrow in and out of the "Engine". "Extras" starts to sound just like the "Engine".
Moving stuff to "Extra" solves very little other than save a bit of space, and mostly caters to our obsesive-compulsive sense of neatness. But it _doesn't_ buy functionality. It just buys a bit of space. And space is cheap. Very cheap. On the other hand, it creates a lot of work for both users and developers. And their time (and mindshare) are very, very expensive. This is why it's a poor trade.
We have to have the courage to say what is part of the platform. And once we commit to something, we have to live up to the expectations. People *need* that to be able to build for Linux. It's essential. There's no reason why we shouldn't do it. We do that for kernel. We do it for glibc. And a bunch of others. But we need to do it for more libs, we can't have in 2005 a platform made up of only some basic libraries. We said GNOME is that platform -- we better live up to our promise.
On Thu, Apr 07, 2005 at 06:49:43PM -0400, Dimitrie O. Paun wrote:
Because it's no longer easily/immediately available. And nowadays it doesn't much matter if things are or aren't possible, but rather if they are easily or not accessible. More often then not, if someting is not working right out of the gate, it's not available for all intents and purposes.
And neither would anything that *uses* gtk+ be easily/immediately available, by your same argument. So why include gtk+-1.2?
John Thacker
On Thu, Apr 07, 2005 at 07:47:44PM -0400, John Thacker wrote:
And neither would anything that *uses* gtk+ be easily/immediately available, by your same argument. So why include gtk+-1.2?
Because it is a library. Users don't use libraries, they use apps to perform tasks. Now, I can see how we can switch an app (say XMMS) with another one that allows the user to perform the same task. That's OK. But users alo use apps that we don't distribute, and it's *those* that we shouldn't break. If we expect users to use *only* the apps we ship, then you'd be right. But in that case we wouldn't have a platform, because we accept a priori that the user will never use other apps.
I don't think we want that.
On Thu, Apr 07, 2005 at 08:05:07PM -0400, Dimitrie O. Paun wrote:
Because it is a library. Users don't use libraries, they use apps to perform tasks. Now, I can see how we can switch an app (say XMMS) with another one that allows the user to perform the same task. That's OK. But users alo use apps that we don't distribute, and it's *those* that we shouldn't break. If we expect users to use *only* the apps we ship, then you'd be right. But in that case we wouldn't have a platform, because we accept a priori that the user will never use other apps.
But users also use apps that have binary kernel modules that we don't distribute.
They used VMWare and NVidia drivers that didn't work on kernel 2.6. Did we: 1) Ship 2.6 and expect the binary providers to catch up, or 2) Not ship something that would break the binaries, or 3) Dual ship 2.6 and 2.4, and continue to dual ship them, as people might still have the older versions around and want to use them? What if they paid for an old version of VMWare that doesn't work on kernel 2.6 and they want to run it on the new Fedora Core, and don't want to be "forced to upgrade?"
Similarly, we expected people to have to do export LD_ASSUME_KERNEL=2.2.5, etc., because their old apps (like acroread4) wouldn't work otherwise. That seems pretty hard for a newbie to figure out; I've had to tell people about it. They don't like their apps suddenly breaking on upgrade.
Basically every release has broken binary applications. RedHat has been the traditional *leader* in breaking apps, in fact. Most of the rest of the argument I could make was eloquently explained by Toshio.
John Thacker
On Thu, Apr 07, 2005 at 09:09:53PM -0400, John Thacker wrote:
They used VMWare and NVidia drivers that didn't work on kernel 2.6.
I think it's a gross exageration to compare such an speciality app with one that uses the standard toolkit. Even windows broke such apps as VMWare, and nobody complained. But regular apps written to the standard toolkit still work on Windows 15+ years later.
Besides, VMWare and NVidia make use of internal stuff that is *explicitly* off limits. Linus doesn't break *exported* interfaces. He is a man of his word, one can say. Similarly, we shouldn't break our exported interfaces.
Similarly, we expected people to have to do export LD_ASSUME_KERNEL=2.2.5, etc., because their old apps (like acroread4) wouldn't work otherwise. That seems pretty hard for a newbie to figure out; I've had to tell people about it. They don't like their apps suddenly breaking on upgrade.
And users have a right to be pissed. It's our failure that we did broke their apps, we shouldn't look at that for inspiration. If anything, we should avoid it like the plague.
Look, I've been using Linux for 10 years. I love it, I'm a hard core user and developer. I don't use it because stuff breaks. We can do without that nonsense. Linus 'gets it', why can't we?
On Thu, Apr 07, 2005 at 09:36:49PM -0400, Dimitrie O. Paun wrote:
I think it's a gross exageration to compare such an speciality app with one that uses the standard toolkit. Even windows broke such apps as VMWare, and nobody complained. But regular apps written to the standard toolkit still work on Windows 15+ years later.
I grant that it's different when you talk about toolkits versus things like glibc and a.out where recompiling fixes most problems. Source compatibility and binary compatibility are different.
But, considering that I don't see qt 2.x around anymore (it was in RH9 but not FC1), and it's neither source nor binary compatible with qt 3.x, and I don't see a lot of other older compatibility stuff around, I wouldn't be suprised if gtk+ went to Extras after nothing in Core needed it. We don't include gtk+ 1.0.x, even though it's also incompatible with gtk+ 1.2.
John Thacker
On Thu, Apr 07, 2005 at 10:25:25PM -0400, John Thacker wrote:
But, considering that I don't see qt 2.x around anymore (it was in RH9 but not FC1), and it's neither source nor binary compatible with qt 3.x,
Not everything we ship has to be part of the platform. That would be crazy and counterproductive, I agree. We must carefully pick our exported (and supported) interface. For the record, I don't consider QT part of the platform because of licensing (but I don't want to start a flamefest, so let's leave it at that :)).
and I don't see a lot of other older compatibility stuff around, I wouldn't be suprised if gtk+ went to Extras after nothing in Core needed it. We don't include gtk+ 1.0.x, even though it's also incompatible with gtk+ 1.2.
In the past we could get away with breakage such as this. There wasn't even a pretense of a platform back in the day, so 3rd parties (outside of OSS) didn't bother to build for it.
I hope we're all trying to change that, and establish Linux as a serious platform. That means we need to be careful what we depracate and how we handle binary compatibility. Whatever we did in the past can not be used as an argument for the future (or present for that matter).
On Thu, 07 Apr 2005 21:09:53 -0400, John Thacker wrote:
Similarly, we expected people to have to do export LD_ASSUME_KERNEL=2.2.5, etc., because their old apps (like acroread4) wouldn't work otherwise. That seems pretty hard for a newbie to figure out; I've had to tell people about it. They don't like their apps suddenly breaking on upgrade.
LD_ASSUME_KERNEL was an absolute usability disaster, it's not something anyone should be pointing to as justification. Threading really was not a bottleneck on most peoples systems, and it would have made much more sense for NPTL to be opt-in, instead of opt-out.
The end result of stuff like this is that all the good work projects like GNOME have done gets thrown away, because the moment Joe User wants to run a cool game or their mission critical app, they have to dick about with the command line setting obscure meaningless variables that you Just Have To Know.
thanks -mike
On Fri, 2005-04-08 at 19:02 +0100, Mike Hearn wrote:
On Thu, 07 Apr 2005 21:09:53 -0400, John Thacker wrote:
Similarly, we expected people to have to do export LD_ASSUME_KERNEL=2.2.5, etc., because their old apps (like acroread4) wouldn't work otherwise. That seems pretty hard for a newbie to figure out; I've had to tell people about it. They don't like their apps suddenly breaking on upgrade.
LD_ASSUME_KERNEL was an absolute usability disaster, it's not something anyone should be pointing to as justification. Threading really was not a bottleneck on most peoples systems, and it would have made much more sense for NPTL to be opt-in, instead of opt-out.
The end result of stuff like this is that all the good work projects like GNOME have done gets thrown away, because the moment Joe User wants to run a cool game or their mission critical app, they have to dick about with the command line setting obscure meaningless variables that you Just Have To Know.
You know, usually the workaround is opt-in instead of default, and for good reasons: if you change things (supposedly for the better), you want applications to be adjusted/fixed if necessary. This works so much better if you need to opt-in for the workaround to let old apps run -- the pressure for application developers to fix their applications is higher. With Windows, you would usually just have to bite the dust if your application doesn't work on the next OS version -- LD_ASSUME_KERNEL being awkward for the end user beats this hands down. Of course it would be even better if there were some kind of infrastructure to handle this better for the easily intimidated ;-).
Nils
On Fri, 0 Apr 2005 20:09:33 +0200, Nils Philippsen wrote:
You know, usually the workaround is opt-in instead of default, and for good reasons: if you change things (supposedly for the better), you want applications to be adjusted/fixed if necessary. This works so much better if you need to opt-in for the workaround to let old apps run -- the pressure for application developers to fix their applications is higher.
I'm afraid the patch life for an average game is about 6 months. After this developers are usually not interested in releasing bugfixes or patches, no matter what sales are like.
This also does nothing for things like Domino, which ship their own copies of the JVM. You can't upgrade it because the whole reason they ship their own JVM is that Java isn't sufficiently backwards compatible enough for large, complex programs like the Domino groupware server to use the systems copy.
End result -> broken apps that will never, ever be fixed.
thanks -mike
Le samedi 09 avril 2005 à 13:14 +0100, Mike Hearn a écrit :
This also does nothing for things like Domino, which ship their own copies of the JVM. You can't upgrade it because the whole reason they ship their own JVM is that Java isn't sufficiently backwards compatible enough for large, complex programs like the Domino groupware server to use the systems copy.
They ship their own copy because the system copy was historically a mess. At some point in time they'll have to either use the system copy or ship a full system image, and hope users won't lynch them.
It's not so much a technical issue as a mindset issue - having several different teams maintaining the same code because they've all decided cooperating is too much work makes little technical sense really.
On Sat, 09 Apr 2005 14:37:05 +0200, Nicolas Mailhot Nicolas.Mailhot@laPoste.net wrote:
It's not so much a technical issue as a mindset issue - having several different teams maintaining the same code because they've all decided cooperating is too much work makes little technical sense really.
In theory this is right, in practice this can be wrong.
Java runtimes have been problematic because getting good performance and reliability out of java requires good code generation, threads, locking and garbage collection. Writing a demanding application is a matter of negotating a style of using threads and memory that works. Small changes to the semantics that still result in 'correct' behavior (matches the spec) can lead to an app that seizes up periodically, ringing your pager at 2 am.
There is something to say for staying on the bleeding edge... Particularly if your level of support from the product developers is good enough that you can get hard problems fixed rapidly. If, on the other hand, you're getting your support from your average vendor (such as a certain market leading Linux distribution) you'll need to take a very large number if you have a hard problem, and in the interest of keeping your line-of-business system up, you'll stick with what works.
On Lun 11 avril 2005 16:56, Paul A. Houle a écrit :
There is something to say for staying on the bleeding edge... Particularly if your level of support from the product developers is good enough that you can get hard problems fixed rapidly. If, on the other hand, you're getting your support from your average vendor (such as a certain market leading Linux distribution) you'll need to take a very large number if you have a hard problem, and in the interest of keeping your line-of-business system up, you'll stick with what works.
The problem being in my experience the carefully debugged version-frozen jvms do not work that much better in practice. Because no matter what the people who specify them wish, customers will require their apps to work on current OSs (current meaning RHEL six months after initial release or older one with all security patches)
App vendors usually test jvm to death with the OS version they have during development, then the testing budget is exhausted, and jvms are "certified" with the following OS releases despite having only cursory app vendor testing (because no one dares telling the truth to management about the whole situation, not certifying them would be commercial suicide, and testing them properly would cost too much).
Not surprisingly, the end result crashes.
The jvms OS vendors ship might not be tuned perfectly but at least they work and distributions will fix them if they don't. App vendors support will tell you to use the unsecure underperforming entreprise linux version that was already old when they tested against it. And that after paying $$$$ for gold support.
If they don't have the resources to keep their jvm current with OS releases, they should be honnest and team with jvm/OS vendors (ie push the fixes they need upstream during their testing phase, and rely on upstream not to break it afterwards). They do rely on kernel/libc vendor packages, and they're as impacting performance-wise.
Regards,
On Mon, 11 Apr 2005 17:23:23 +0200 (CEST), Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
App vendors usually test jvm to death with the OS version they have during development, then the testing budget is exhausted, and jvms are "certified" with the following OS releases despite having only cursory app vendor testing (because no one dares telling the truth to management about the whole situation, not certifying them would be commercial suicide, and testing them properly would cost too much).
Not surprisingly, the end result crashes.
Yeah sure, but once I get a system that works, that doesn't wake me up at night because it went down at 2 am, I'm inclined to sit on it.
The jvms OS vendors ship might not be tuned perfectly but at least they work and distributions will fix them if they don't. App vendors support will tell you to use the unsecure underperforming entreprise linux version that was already old when they tested against it. And that after paying $$$$ for gold support.
Maybe, maybe not.
I've got a limited amount of faith in vendors. My productivity as a developer was destroyed for about six months that I had to deal with race conditions or deadlock issues in the defective 2.4 kernel that shipped with RHEL 3. We bought RHEL through a third-party vendor, so support was useless, and I doubt that we'd have done better if we'd talked directly to RH. It probably would have taken a nearly-identical test machine and a few weeks of time from a full-time kernel developer to have fixed our problem, probably a total cost of 10x our yearly registration cost.
An upgrade to 2.6 solved the problem.
I do have faith in the 2.6 kernel, but I'm more interested in catching up with six months of lost time than I am in spending another few months screwing around with buggy software.
If they don't have the resources to keep their jvm current with OS releases, they should be honnest and team with jvm/OS vendors (ie push the fixes they need upstream during their testing phase, and rely on upstream not to break it afterwards). They do rely on kernel/libc vendor packages, and they're as impacting performance-wise.
Yeah, I wish that were all possible.
But there's a lot of nonsense in this world.
For years, RH shipped a free 'java' runtime that was completely broken, wouldn't run any real java applications, and ran toy applications with an order of magnitude worse performance than commercial java implementations.
The skills and knowledge about code generation, concurrency control, memory allocation and garbage collection in the open source world have been largely insufficient to make workable java implementations.
(Yes, the new gcc-java is a big step forward, but it's still quite quirky, and it's overall success depends on dumping AWT and Swing into the trashcan.)
Sun's software strategy is unclear (how could they possibly make money off of Java?) and their relationship with Linux is problematic. (A few years ago they laid off the developers of Solaris x86, now they're coming on full-force with Solaris 10 as a competitor against Linux.)
IBM has it's own Java runtime which is a derivative of Sun's -- at times they've put some good work in it. God bless IBM, but you can only count on them so far for support.
The 2.6 kernel team is doing big things, often really good things. Will those things introduce subtle breakages involving Java threads? Quite likely. Is it really fair to Sun and IBM to expect their engineers to solve problems immediately because some kernel developer had a 'good' idea they wanted to try out?
The kind of model you're talking about, in a lot of ways, might be easier when we're dealing with the kind of single-vendor hardware stack that you're likely to get from Apple or with SPARC/Solaris from Sun.
Le lundi 11 avril 2005 à 11:54 -0400, Paul A. Houle a écrit :
The 2.6 kernel team is doing big things, often really good things. Will those things introduce subtle breakages involving Java threads? Quite likely. Is it really fair to Sun and IBM to expect their engineers to solve problems immediately because some kernel developer had a 'good' idea they wanted to try out?
Well, the other language people seem to manage it. And actually the elapsed time between a change appearing on kernel.org and the same change getting in RHEL is large enough to expect things (J2EE) work on RHEL from day one, and less demanding stuff (J2SE) likewise in FC.
Of course that requires worrying about the change when it starts being proposed on lkml, not when the RHEL release is out.
Linux development is public, don't tell me vendors haven't got loads of time to adapt. No one is springing secret apis on them here.
Regards,
On Fri, Apr 08, 2005 at 07:02:25PM +0100, Mike Hearn wrote:
LD_ASSUME_KERNEL was an absolute usability disaster, it's not something anyone should be pointing to as justification. Threading really was not a bottleneck on most peoples systems, and it would have made much more sense for NPTL to be opt-in, instead of opt-out.
The end result of stuff like this is that all the good work projects like GNOME have done gets thrown away, because the moment Joe User wants to run a cool game or their mission critical app, they have to dick about with the command line setting obscure meaningless variables that you Just Have To Know.
And the end result of making things like NPTL opt-in is that really broken things never get fixed, because those old binaries using broken things are still lying around.
There's an entire continuum along the way of doing things, and there are certainly tradeoffs involved either way. Since most of the ill effects of doing things the Linux way (and the RedHat way) of making incompatible changes in order to discard cruft both fall hardest on non Free Software and non Open Source Software and on less technical users, it is unsurprising that Linux distributions are much more likely to behave this way than Windows, being both inherently more hostile to closed binaries and with a more technically savvy user communitiy. (It is, I think, worth pointing out that even an average user has no problems provided that he stays with Free Software.)
While I certainly do not blame you for wanting a different balance in your approach, I disagree with your opinion as I place a different value on fixing broken things versus compatibility. While it is unreconcilable, luckily you and others are free to create a distribution which does take backwards compatibility more seriously. (Or use the many other operating systems that take a hardline approach towards backwards compatibility at the expense of fixing things.) I respect your differing opinion and recognize the tradeoffs involved, but still prefer things the way that they have been done. No invocation of "but we're a *platform* now" is likely to make me change my mind.
John Thacker
On Thu, Apr 07, 2005 at 06:49:43PM -0400, Dimitrie O. Paun wrote:
We have to have the courage to say what is part of the platform. And once we commit to something, we have to live up to the expectations. People *need* that to be able to build for Linux. It's essential. There's no reason why we shouldn't do it. We do that for kernel. We do it for glibc. And a bunch of others. But we need to do it for more libs, we can't have in 2005 a platform made up of only some basic libraries. We said GNOME is that platform -- we better live up to our promise.
"We do that for kernel." What? Where do we ship a 2.4 version kernel (and 2.2, and 2.0, etc.) in order to have FC work with applications that don't run with 2.6? The compat-gcc libraries are there, certainly, but "we do it for glibc?" compat-glibc wasn't included in even RedHat 9, so any old RedHat 6.x binaries using glibc2.1 are out of luck. (Of course, forget about old libc5 stuff.) RedHat 9 nuked compatibility with anything pre-Redhat 7.x.
John Thacker
On Thu, Apr 07, 2005 at 07:58:36PM -0400, John Thacker wrote:
"We do that for kernel." What? Where do we ship a 2.4 version kernel (and 2.2, and 2.0, etc.) in order to have FC work with applications that don't run with 2.6?
Of course we don't, that's why Linus is fanatic in keeping binary compatibility. That's why apps compiled against Linux 0.9 still run a decade later on 2.6.x. Unmodified.
The compat-gcc libraries are there, certainly, but "we do it for glibc?" compat-glibc wasn't included in even RedHat 9, so any old RedHat 6.x binaries using glibc2.1 are out of luck. (Of course, forget about old libc5 stuff.) RedHat 9 nuked compatibility with anything pre-Redhat 7.x.
Of course they did. At the time, we didn't even pretend to be a platform, and so there was no love lost. But now we do, the name of the game changed. And mind you, we shouldn't break binary compatibility in glibc, it was unfortunate that we did. That should be the exception, not the rule.
On Thu, Apr 07, 2005 at 08:09:45PM -0400, Dimitrie O. Paun wrote:
On Thu, Apr 07, 2005 at 07:58:36PM -0400, John Thacker wrote:
"We do that for kernel." What? Where do we ship a 2.4 version kernel (and 2.2, and 2.0, etc.) in order to have FC work with applications that don't run with 2.6?
Of course we don't, that's why Linus is fanatic in keeping binary compatibility. That's why apps compiled against Linux 0.9 still run a decade later on 2.6.x. Unmodified.
But not on Fedora Core, they won't, I'm fairly sure. Remember a.out binaries? http://www.ofb.net/~jheiss/aout_redhat.shtml
[jat48@thacker SOURCES]$ grep AOUT kernel-2.6.11-i686.config # CONFIG_BINFMT_AOUT is not set [jat48@thacker i386]$ ls -l /lib/ld- ld-2.3.4.so ld-linux.so.2 And the lack of libc.so.4, in addition to libc5 and the aforementioned glibc21.
Except for users who consider their binary drivers to be "apps," or at least essential to running certain applications or games. If they upgrade the kernel and suddenly they can't play games because they don't have accelerated 3D drives, that's going to look like a problem.
Then there are "apps" like VMWare that require kernel modules. Those have to be recompiled when the kernel changes, and the kernel interface does change enough to cause problems. See: http://thomer.com/linux/migrate-to-2.6.html
This one actually rather confuses me: http://icculus.org/lgfaq/#descent326oh
"Q: Descent 3 doesn't work on my 2.6 kernel, how can I fix it?
A: su - to root, cd to your Descent 3 directory (/usr/local/games/descent3, usually). Then ln -s ppics.hog PPics.Hog "
John Thacker
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dimitrie O. Paun wrote:
On Thu, Apr 07, 2005 at 05:43:14PM -0400, John Thacker wrote:
And when nothing in Core requires it, what's wrong with moving it to Extras?
Moving stuff to "Extra" solves very little other than save a bit of space, and mostly caters to our obsesive-compulsive sense of neatness. But it _doesn't_ buy functionality. It just buys a bit of space. And space is cheap. Very cheap. On the other hand, it creates a lot of work for both users and developers. And their time (and mindshare) are very, very expensive. This is why it's a poor trade.
Extras buys more than space. It buys time as well. By eliminating the maintenance of cruft fedora core developers are able to spend more of their time actually improving core applications and as a result increase the rate of innovation in these areas. Less maintenance work and a cleaner picture of the horizon means more work *can" be done towards a clearer vision. Time *and* space... now thats a bargain. ;)
- -- Michael Favia michael.favia@insitesinc.com Insites Incorporated http://michael.insitesinc.com
On Wed, 2005-04-06 at 15:30 +0100, Mike Hearn wrote:
Now, I want to see Linux - and Fedora Core - be operating systems. I want to see lots of people building their software upon Free APIs, and I think we need to compete with Windows and MacOSX to get there. So I'd lean towards the second view.
Mike, I definitely can agree with the portion of your argument shown here:: One of Window's selling points is its compatibility to old versions. It is, in fact, the center of the Microsoft business model. If Longhorn were to totally break compatibility with previous versions of Windows, how many shops do you think would decide it made just as much sense to break compatibility and move to a better OS than to stay with an incompatible "Windows"?
OTOH, Linux distributions aren't being used because they're just like Windows. They're being used because they have other unique strengths. One of which is the willingness to do painful things like get rid of old cruft in order to make way for different, incompatible advances. I think for Fedora's goals (moving faster than RHL was, testing new technologies for eventual inclusion in RHEL, not being a dumping ground for old, unmaintained code), sacrificing the ability to get rid of cruft (in Core) for compatibility to old binaries/APIs is a poor decision.
Someone pointed out that many of the Loki Games no longer run on Fedora because of kernel changes. No amount of keeping old libraries is going to overcome that. If someone wants to fork a version of Fedora that gets updated applications but keeps a stable base down to the kernel layer and vet all potential changes there for things that will break user apps they might be able to garner market share from people wanting to run third party binary apps forever. OTOH, they may find that corner of the market (game and app-rich, API/ABI stable, binary and proprietary-license friendly OSs) is already filled with more mature competitors.
-Toshio
On Thu, 07 Apr 2005 18:31:25 -0400, Toshio toshio@tiki-lounge.com wrote:
Mike, I definitely can agree with the portion of your argument shown here:: One of Window's selling points is its compatibility to old versions. It is, in fact, the center of the Microsoft business model. If Longhorn were to totally break compatibility with previous versions of Windows, how many shops do you think would decide it made just as much sense to break compatibility and move to a better OS than to stay with an incompatible "Windows"?
Microsoft has another motivation for keeping binary compatibility.
If a new version of Windows breaks a major application that competes with a Microsoft app, they'll have the DOJ on their case.
Someone pointed out that many of the Loki Games no longer run on Fedora because of kernel changes. No amount of keeping old libraries is going to overcome that. If someone wants to fork a version of Fedora that gets updated applications but keeps a stable base down to the kernel layer and vet all potential changes there for things that will break user apps they might be able to garner market share from people wanting to run third party binary apps forever. OTOH, they may find that corner of the market (game and app-rich, API/ABI stable, binary and proprietary-license friendly OSs) is already filled with more mature competitors.
The guy who lives in our other house is mad because an upgrade to Win2K broke his favorite games that ran just fine on Win98. I dread installing a DirectX game on any of the Windows machine I use because the odds of it working aren't that good. A lot of times it's a problem with the video card, drivers, and all that, but these problems aren't easy to fix.
Back in 2000, I caught the USB bug and started getting USB peripherals of all types. I had much better luck plugging USB devices into Linux than I had plugging them into Win98. With mplayer, I can play just about any video file I get off the net. I've installed all sorts of libraries on my Windows and MacOS X systems and neither of them reliably and correctly plays XViD files.
Windows and MacOS X have a lot to teach Linux about having a better desktop experience, but don't kid yourself into thinking they're perfect.
On Tue, 2005-04-05 at 23:37 +0100, Mike Hearn wrote:
What else deps on gtk+ 1.X?
You can't drop GTK1 unless you want to break every single Loki Setup out there.
Are there many Loki setups out there? IIRC, they stopped making games, didn't they?
After that, its a simple "yum install gtk1" or similar to allow folk to get their Loki games working again. Yes, Extras repository information should be available (and enabled) in Core 4
On Thu, 07 Apr 2005 23:01:09 +1000, Colin Charles wrote:
Are there many Loki setups out there? IIRC, they stopped making games, didn't they?
Loki Setup is a generic program used by nearly all commercial vendors on Linux. It's not just the old Loki games (which are mostly broken thanks to other platform instabilities like NPTL anyway) but games like Doom III and programs like CrossOver also come in this form.
After that, its a simple "yum install gtk1" or similar to allow folk to get their Loki games working again. Yes, Extras repository information should be available (and enabled) in Core 4
That's fine, but how does the user know this? "yum install gtk1" is a very UNIXy sort of command for an end user desktop, isn't it?
thanks -mike
On Apr 7, 2005 9:24 AM, Mike Hearn mike@navi.cx wrote:
That's fine, but how does the user know this? "yum install gtk1" is a very UNIXy sort of command for an end user desktop, isn't it?
So let's get this straight.. not only do you want gtk1 as part of Core... you want it installed by default as part of the Desktop install? In fc3 gtk+-1.x is part of the "compat-arch-support" group, and I'm pretty sure that stuff is not part of a default Desktop. And I am unaware of any default application that sucks in gtk+-1.x into a desktop install as a requirement, even gnucash and xmms are optional applications.
So assuming in fc3 doesn't install gtk+ by default... the change to extras doesn't effectively change the level of difficulty to get the package. In fc3 you still have to do something unixy to get the package installed. Don't even bother with s-c-packages as a counter argument. As soon as you install ANY updates from the network s-c-packages becomes effectively useless as an operational tool because it is unaware of the pool of updates and associated dependancy matrix.
-jef
On Thu, 07 Apr 2005 10:27:08 -0400, Jeff Spaleta wrote:
So let's get this straight.. not only do you want gtk1 as part of Core... you want it installed by default as part of the Desktop install?
Yes. Having things work out of the box is the whole point, isn't it?
fc3 gtk+-1.x is part of the "compat-arch-support" group, and I'm pretty sure that stuff is not part of a default Desktop. And I am unaware of any default application that sucks in gtk+-1.x into a desktop install as a requirement, even gnucash and xmms are optional applications.
I don't know. I never explicitly installed it yet it's here, on the other hand I upgraded from a previous FC2 install. XMMS is pretty common though.
So assuming in fc3 doesn't install gtk+ by default... the change to extras doesn't effectively change the level of difficulty to get the package. In fc3 you still have to do something unixy to get the package installed.
Well that's even worse!
thanks -mike
On Thu, Apr 07, 2005 at 04:12:11PM +0100, Mike Hearn wrote:
On Thu, 07 Apr 2005 10:27:08 -0400, Jeff Spaleta wrote:
So let's get this straight.. not only do you want gtk1 as part of Core... you want it installed by default as part of the Desktop install?
Yes. Having things work out of the box is the whole point, isn't it?
I don't know. I never explicitly installed it yet it's here, on the other hand I upgraded from a previous FC2 install. XMMS is pretty common though.
But everything included does work out of the box. And newbies have a way to play music out of the box. And if you explicitly install something that requires gtk+, it'll install it. (Say, gnucash.) And Extras will be enabled by default, so it's not much different from the upgrade process. All sorts of outside programs require making sure that all sorts of certain libraries are installed.
I don't think it's too much to ask for a user to who wants to install extra programs to learn how to use yum or some other update program. They ought to be updating for security anyway.
I'm biased; my feelings for some time have been "Die, XMMS, Die!" I like their playlist-based approach much better than Rhythmbox, but their refusal to move away from gtk+ is frustrating. I get along perfectly well without gtk+, and don't like installing it for just one program. I consider gtk+ inherently broken at this point, for its poor internationalization support by comparison with gtk2 if nothing else.
John Thacker
Once upon a time, John Thacker thacker@math.cornell.edu said:
I'm biased; my feelings for some time have been "Die, XMMS, Die!" I like their playlist-based approach much better than Rhythmbox, but their refusal to move away from gtk+ is frustrating. I get along perfectly well without gtk+, and don't like installing it for just one program.
Users don't care about the libraries though; it's all about the apps.
Maybe I've just missed something, but the times I tried I didn't see a quick and easy way to just open a random sound file and play it in Rhythmbox. I guess I'll look again, or I'll just install xmms (and whatever it requires) from FE.
On Thu, Apr 07, 2005 at 10:52:19AM -0500, Chris Adams wrote:
Maybe I've just missed something, but the times I tried I didn't see a quick and easy way to just open a random sound file and play it in Rhythmbox. I guess I'll look again, or I'll just install xmms (and whatever it requires) from FE.
Try amarok (from FE).
Le jeudi 07 avril 2005 à 10:52 -0500, Chris Adams a écrit :
Once upon a time, John Thacker thacker@math.cornell.edu said:
I'm biased; my feelings for some time have been "Die, XMMS, Die!" I like their playlist-based approach much better than Rhythmbox, but their refusal to move away from gtk+ is frustrating. I get along perfectly well without gtk+, and don't like installing it for just one program.
Users don't care about the libraries though; it's all about the apps.
Believe me, when using an old lib like gtk+ that directly translates into "you will only use acsii, else" they _do_ care about the lib factor.
I still remember the lengths people went to to get a fontconfig-enabled moz build back when fontconfig was new. And it was "just a library" too.
Regards,
On Thu, Apr 07, 2005 at 07:47:33PM +0200, Nicolas Mailhot wrote:
Le jeudi 07 avril 2005 à 10:52 -0500, Chris Adams a écrit :
Users don't care about the libraries though; it's all about the apps.
Believe me, when using an old lib like gtk+ that directly translates into "you will only use acsii, else" they _do_ care about the lib factor.
Indeed. I study Japanese as well, and have some ogg files whose tags are in Japanese. Rhythmbox works perfectly well for displaying them. xmms gives utter gibberish.
I care about the apps. And that means being biased against anything which can't display languages other than English (or just Western European languages.) Since essentially everything using gtk+ works poorly with multiple charsets, that's a bias against gtk+. (Yes, sylpheed's stable version works pretty darn well with gtk+ and Japanese. It's much more the exception than the rule, though.)
Internationalization is *hard* with gtk+. CJK support and complex rendering language support requires thinking in all sorts of ways that programmers who speak only Western European languages don't usually. gtk2, pango, and fontconfig make it almost automatic. So I don't think I'm too crazy here.
John Thacker
On Apr 7, 2005 11:12 AM, Mike Hearn mike@navi.cx wrote:
On Thu, 07 Apr 2005 10:27:08 -0400, Jeff Spaleta wrote:
So let's get this straight.. not only do you want gtk1 as part of Core... you want it installed by default as part of the Desktop install?
Yes. Having things work out of the box is the whole point, isn't it?
Having commercial addon things that can't keep up with the pace of development of fedora core work out of the box is the point? I don't think so. I'm actively hostile to any decision that stresses the needs of slow moving commercial vendors in the decision making process for fedora core development. Especially when those commercial vendors are using some sort of package installation method that doesn't interface with the management system fedora is using. If those vendor packages were using rpms or interfaced with rpm... this sort of dependancy problems could just evaporate through established dependancy resolution mechanisms that rpm and repository tools use.
I don't know. I never explicitly installed it yet it's here, on the other hand I upgraded from a previous FC2 install. XMMS is pretty common though.
xmms maybe common for advanced users.. but its NOT part of a default desktop setup in fc3. And in fc4.. with xmms no longer IN Core.. your argument holds even less water than it did. As soon as nothing in Core depends on gtk+, expect it to be dropped. Since it appears gnucash isn't going anywhere yet, you most likely do not have to worry about this in the fc4 time frame. BUT if you are concerned about this, you better talk to the commercial vendors whose products are relying on gtk+ to be present and give them a big heads-up and encourage them to find a gtk2 based solution.
Well that's even worse!
So if the current situation is even worse than you realize... perhaps your arguing about the wrong thing. Libraries and components that aren't going to be actively used by applications IN core are going to be dropped over time... its the only way to make room for new things that need to be in Core. The issue of compatibility libraries is a larger issue than just gtk+, we can not keep all useful compatibility libraries in Core and make progress on best-of-breed applications. New things will have to replace old things, old things will have to be moved out. Instead people like yourself who are concerned about this, need to find a way to make the installation of compatibility items 'just work' when they are needed.. if they are needed... on individual systems.
-jef"worrying about ANY commercial vendor's development timescale is an absolutely sure way to stagnate this project"spaleta
On Thu, 07 Apr 2005 11:34:31 -0400, Jeff Spaleta wrote:
Having commercial addon things that can't keep up with the pace of development of fedora core work out of the box is the point?
Uh, as already pointed out Loki Setup is open source. Being non-commercial doesn't magically mean people jump up and down to rewrite it every few years.
I don't think so. I'm actively hostile to any decision that stresses the needs of slow moving commercial vendors in the decision making process for fedora core development.
What makes you think ID Software are slow moving? Maybe it's just that rewriting code that's been tested, debugged and successfully deployed for little to no benefit is a recipe for commercial disaster?
Seriously. Often these programs aren't internationalised at all, so better i18n support isn't a compelling reason to rewrite Loki Setup, and neither is support for the latest theme engines. It's only a setup program, after all.
Especially when those commercial vendors are using some sort of package installation method that doesn't interface with the management system fedora is using ...
Except they don't all use RPMs, for well documented reasons. Let's not get into that one again.
So if the current situation is even worse than you realize... perhaps your arguing about the wrong thing. Libraries and components that aren't going to be actively used by applications IN core are going to be dropped over time... its the only way to make room for new things that need to be in Core.
No it's not. Windows XP provides compatibility for applications written over a decade ago, yet it still fits on one CD.
The definition of what's "core" and what isn't seems pretty vague to me. There's no need to drop things as more stuff is added, just be more conservative about adding things! There's no need for FC to have loads of apps out of the box. It's more important IMHO that it's easy to use and Just Works.
Instead people like yourself who are concerned about this, need to find a way to make the installation of compatibility items 'just work' when they are needed.. if they are needed... on individual systems.
There's no way to do this currently. Possibly if distributions had provided a single consistent packaging scheme from the start, Loki Setup would never have been written. But it didn't work out that way, and now we have a legacy issue to deal with. Sucks but that's life. Maybe there are lessons to learn here.
-jef"worrying about ANY commercial vendor's development timescale is an absolutely sure way to stagnate this project"spaleta
Yeah right, just like MacOS X is stagnating. Whatever.
thanks -mike
On Thu, Apr 07, 2005 at 04:59:51PM +0100, Mike Hearn wrote:
No it's not. Windows XP provides compatibility for applications written over a decade ago, yet it still fits on one CD.
Well, if we strip down Core to the amount of functionality that a freshly installed Windows XP is able to provide, we can do with one CD, too, I think.
On Thu, Apr 07, 2005 at 04:59:51PM +0100, Mike Hearn wrote:
No it's not. Windows XP provides compatibility for applications written over a decade ago, yet it still fits on one CD.
Yes, but Windows XP includes lots of hacks to the API (a very intensive effort), and doesn't include lots of apps on that one CD. You're comparing apples to oranges. If Fedora Core were to contain only basic libraries, yum, coreutils, and a web browser, then one CD would be possible.
For example, if you want Office, that adds CDs to the XP install.
John Thacker
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John Thacker wrote:
On Thu, Apr 07, 2005 at 04:59:51PM +0100, Mike Hearn wrote:
No it's not. Windows XP provides compatibility for applications written over a decade ago, yet it still fits on one CD.
For example, if you want Office, that adds CDs to the XP install.
Perhaps this would present an interesting alternative to organizing the packages on cd's. I know it has been discussed ad nauseum on this list but a "Basic Graphical" intsall that required only the first cd would provide a large group of core users all of the tools they need to fill in the missing application gaps (OOo, GIMP, etc). Especially is pup sees the light of day soon enough. Is this really possible?
- -- Michael Favia michael.favia@insitesinc.com Insites Incorporated http://michael.insitesinc.com
On Thu, 07 Apr 2005 12:02:33 -0400, John Thacker wrote:
Yes, but Windows XP includes lots of hacks to the API (a very intensive effort), and doesn't include lots of apps on that one CD. You're comparing apples to oranges.
I'm comparing two operating systems. Seems more like Granny Smith vs Braeburn to me.
If Fedora Core were to contain only basic libraries, yum, coreutils, and a web browser, then one CD would be possible.
Go for it. Seems like that'd resolve the constant bickering over what's in Core and what isn't. Just make core the bare essentials for a desktop system - MacOS X and Windows can be useful guides in this respect - and then make it super easy for people to find and install the software they want. Voila - you now have space to put compatibility libraries in, and users don't have to think about details like what a GTK+ is because it's there, out of the box, waiting in case it's needed.
thanks -mike
On Thu, Apr 07, 2005 at 04:59:51PM +0100, Mike Hearn wrote:
Except they don't all use RPMs, for well documented reasons. Let's not get into that one again.
Great. And I don't like newbies using programs that don't use the package system and its dependency calculations, for well documented reasons.
Oh no, they're using a program which doesn't calculate dependencies, and dependencies are a problem. Shock.
John Thacker
On Apr 7, 2005 11:59 AM, Mike Hearn mike@navi.cx wrote:
The definition of what's "core" and what isn't seems pretty vague to me. There's no need to drop things as more stuff is added, just be more conservative about adding things! There's no need for FC to have loads of apps out of the box. It's more important IMHO that it's easy to use and Just Works.
stagnation... thats what you want. Following your logic we could never drop an application, or a library to make room for any new functionality or streamline the system at all. I take it in your world view we should be including a 2.4 and a 2.2 and potentially a 2.0 series kernel for "compatibility" reasons. I mean hell, I know there are some proprietary and open source kernel modules that are well tested and work with 2.4 kernels that havent been ported to the 2.6 kernels yet. Even more so when the 2.4 kernel was dropped outright. If Fedora Core stressed backwards compatibility at the distribution level as strongly as you do, we would never have a 2.6 kernel by default.....stagnation.
Your definition of "just works" is different than mine. I do not consider the full space of all previously written codebases when i talk about "just works." Shall I complain about that fact that the old oneko packages from rhl that i relied on no longer work? Or the fact that the absoft fortran compiler doesn't work without compatibility packages being installed? Solve the general forward looking problem of getting compatibility elements from Extras instead of demanding the set of packages in Core remain stagnant and you'll be everyone's hero.
There's no way to do this currently.
Then build one. Some compatibility items will be moving to extras. If you feel its too cumbersome to people to interact with Extras to find those compatibility pieces.. build the better interface and mechanisms to help those users out. I think its far far too late in the game to be complaining about how compatibility libraries are treated since they haven't been installed by default up till this point. Its going to be far easier for you or anyone else who thinks compatibility libraries is a priority to engineer a solution that works with Extras than to expect priorities to change. But hey, if you want to try to change the course of a river by shaking your finger at it on the riverbank.. please go right ahead.
Possibly if distributions had provided a single consistent packaging scheme from the start, would never have been written. But it didn't work out that way, and now we have a legacy issue to deal with. Sucks but that's life. Maybe there are lessons to learn here.
Yep and its going to be dealt with by moving some compatibility libraries into Extras and having users install them as needed, instead of installing them by default. So anyone who wants to make it easier to get compatibility elements installed should focus on making it easier to interact with Extras as needed when needed.
Yeah right, just like MacOS X is stagnating. Whatever.
That's an obnoxiously silly comparison. MacOS X is a for pay product that encompasses non open software elements which are developed in a highly closed process. apples to oranges comparison. Fedora's long term development priorities are publicly available as a guidance for this project, MacOS X's are not. And I dare say, as an individual you have far more potential to impact what goes on in fedora through your individual contributions to any specific piece of distribution than you have with the direction of MacOS X development.
-jef
On Thu, 07 Apr 2005 12:47:31 -0400, Jeff Spaleta wrote:
That's an obnoxiously silly comparison. MacOS X is a for pay product that encompasses non open software elements which are developed in a highly closed process. apples to oranges comparison.
It's an operating system that supports third party and commercial development yet it's clearly not stagnating: if anything it's moving faster than the Linux community is.
So my point was your theory about supporting commercial software causing stagnation can't be correct, because there is a fairly obvious counter-example.
What is silly about that?
On Thu, 2005-04-07 at 18:01 +0100, Mike Hearn wrote:
On Thu, 07 Apr 2005 12:47:31 -0400, Jeff Spaleta wrote:
That's an obnoxiously silly comparison. MacOS X is a for pay product that encompasses non open software elements which are developed in a highly closed process. apples to oranges comparison.
It's an operating system that supports third party and commercial development yet it's clearly not stagnating: if anything it's moving faster than the Linux community is.
So my point was your theory about supporting commercial software causing stagnation can't be correct, because there is a fairly obvious counter-example.
Okay, we're off-topic pretty badly where this discussion is going.
take it offlist if you want to bicker about osx vs linux. thanks.
-sv
On Thu, Apr 07, 2005 at 11:01:09PM +1000, Colin Charles wrote:
Are there many Loki setups out there? IIRC, they stopped making games, didn't they?
They went out of business alas.
After that, its a simple "yum install gtk1" or similar to allow folk to get their Loki games working again. Yes, Extras repository information should be available (and enabled) in Core 4
If gtk1 does go that is probably a good FAQ item
Alan
Mike Hearn wrote:
On Tue, 05 Apr 2005 15:14:55 -0400, seth vidal wrote:
What else deps on gtk+ 1.X?
You can't drop GTK1 unless you want to break every single Loki Setup out there.
Not withstanding the other good comments in this thread, I'd like to point out that this isn't the only respect in which older proprietry applications will break. To run quake3 (for example) on a recent Linux distro you need to start doing things like
echo 1 > /proc/sys/vm/legacy_va_layout
Trying to get teamspeak to run along side is even more painful. (Though it's doable - but more effort than finding out you need gdk IMO.)
To be fair, I don't know how the widespread the issues with quake3 are amoungst other Loki games - but I would not be suprised by more issues arising. Without the source or keeping MS-like backwards compatability - what are we going to do?
Let's not even start talking about Oracle installations (though they're improving). ;)
Personally I no longer bother and just keep a Windows installation for running my propriety games.
Cheers
On Thu, 2005-04-14 at 11:50 +0100, Stuart Children wrote:
Mike Hearn wrote:
On Tue, 05 Apr 2005 15:14:55 -0400, seth vidal wrote:
What else deps on gtk+ 1.X?
You can't drop GTK1 unless you want to break every single Loki Setup out there.
Not withstanding the other good comments in this thread, I'd like to point out that this isn't the only respect in which older proprietry applications will break. To run quake3 (for example) on a recent Linux distro you need to start doing things like
echo 1 > /proc/sys/vm/legacy_va_layout
no you don't do this, you do setarch -L quake instead.
(and this is a clear sign of a bad bug in that quake 3 program)
On Apr 5, 2005 3:08 PM, seth vidal skvidal@phy.duke.edu wrote:
On Tue, 2005-04-05 at 15:03 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-04-05 at 15:01 -0400, seth vidal wrote:
On Tue, 2005-04-05 at 14:57 -0400, Ignacio Vazquez-Abrams wrote:
/me waits patiently for gtk+ to drop out and have plenty of people scream bloody murder
what's left that deps on gtk+?
xmms just got dropped out? is it just gnucash that's left?
Yep, that's it.
so when you say 'plenty of people' you meant to say 'the 5 people using gnucash' :-D
And you wonder why people get upset about the attitudes about software maintance in extras?
... I guess with me it's 6 people using gnucash. I don't care if you think it's unimportant: it matters to me (but I guess I don't count as far as you're concerned since I don't have the time to step up and maintain it).
Gregory Maxwell wrote:
On Apr 5, 2005 3:08 PM, seth vidal skvidal@phy.duke.edu wrote:
so when you say 'plenty of people' you meant to say 'the 5 people using gnucash' :-D
And you wonder why people get upset about the attitudes about software maintance in extras?
OK, mister crabby-pants, relax. Seth was only joking (and even posted a followup to explain it explicitly for the smiley-challenged).
-- Rex
On Apr 5, 2005 4:22 PM, Rex Dieter rdieter@math.unl.edu wrote:
Gregory Maxwell wrote:
On Apr 5, 2005 3:08 PM, seth vidal skvidal@phy.duke.edu wrote:
so when you say 'plenty of people' you meant to say 'the 5 people using gnucash' :-D
And you wonder why people get upset about the attitudes about software maintance in extras?
OK, mister crabby-pants, relax. Seth was only joking (and even posted a followup to explain it explicitly for the smiley-challenged).
I'm not crabby. :) I replied before his follow up.
But we really can't expect everyone who can come around to complain about the quality of a package to go fix it, but thats what I see happening when people have complained that a package was moved from core to extras where they feel it will get less love.
I'm not crabby. :) I replied before his follow up.
But we really can't expect everyone who can come around to complain about the quality of a package to go fix it, but thats what I see happening when people have complained that a package was moved from core to extras where they feel it will get less love.
why can't we? If someone is capable of knowing what to complain about why can't they fix it? Especially if they have a vested interest in it.
-sv
On Apr 5, 2005 4:34 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
But we really can't expect everyone who can come around to complain about the quality of a package to go fix it, but thats what I see happening when people have complained that a package was moved from core to extras where they feel it will get less love.
First of all.. how much love a package gets is very dependant on the personal investment of the maintainer who oversees the package (ir)regardless of which tree it actually sits in. A Red Hat employee who assigned to keep a package maintained but isn't personally invested in the package or its development upstream could very well give that package far less love than an interested community member who is personally committed relationship with that package as a user or as an upstream developer. It very much depends. The fact that that people instantly associate better packaging with Core speaks volumes about Red Hat's strength as a brandname..even if the brandname isn't being directly used.
Do you know how many packages the owner of gnucash actually owns in Core? Do you know what other crap this person has to do beyond just keeping up with those packages as a Red Hat employee? You can't evaluate 'love' for a specific package until you have a good understanding of where in the infinite list of priorities the specific maintainer ranks that package. If anything putting crap into Extras gives a package access to more love not less. Upstream developers who live outside the RedHat fence line can be primary or co-maintainer of packages in Extras.. they can't necessarily do that easily inside Core yet.
Contrary to public opinion... an overworked Red Hat employee isn't necessarily the best maintainer compared to an enthusiastic volunteer. The real issue is figuring out a way to mentor those volunteers in the art of packaging and maintainence.... sucking out the juicy marrow of packaging experience from the sulken husks of the Red Hat fossils and transplanting it into young minds of the fresh beasts of burden.
Second of all... there is no second point.
-jef"the (ir) was added to make sure new england natives could understand the sentence"spaleta
On Tue, Apr 05, 2005 at 03:01:11PM -0400, seth vidal wrote:
what's left that deps on gtk+?
xmms just got dropped out? is it just gnucash that's left?
nmap-frontend as well. There's an "evil" port to gtk2, but it really is evil; involves -DGTK_ENABLE_BROKEN. Currently rawhide is building the (evil, broken) gtk2 version, but the spec file incorrectly still requires gtk+. That dependency could be removed/changed depending on whether the flag for building gtk2 is turned on.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153769
John
On Apr 5, 2005 8:16 AM, Ignacio Vazquez-Abrams ivazquez@ivazquez.net wrote:
No argument here, I'm just curious as to why this particular package disappeared.
I did a quick search over the build report annoucements I have cached and I didn't get an obvious hit for a removal annoucement of gnome-vfs. I can't tell if this was delibrate or not.
-jef
Jeff Spaleta (jspaleta@gmail.com) said:
On Apr 5, 2005 8:16 AM, Ignacio Vazquez-Abrams ivazquez@ivazquez.net wrote:
No argument here, I'm just curious as to why this particular package disappeared.
I did a quick search over the build report annoucements I have cached and I didn't get an obvious hit for a removal annoucement of gnome-vfs. I can't tell if this was delibrate or not.
gnome-vfs was removed when nothing required it to build or run any more.
This was done a few weeks ago.
Bill
On Tue, 2005-04-05 at 08:06 -0400, Ignacio Vazquez-Abrams wrote:
From http://fedoraproject.org/wiki/Extras_2fFC4Status:
"gpredict (i386, x86_64) - gnome-vfs-devel - buildreq couldn't be installed"
Yes, why is that anyways? I tried to hunt down a reason in the mailing list archives but couldn't find one.
"couldn't be installed" != "isn't in the tree"
b/c rawhide is rawhide sometimes it just can't be built on.
-sv
On Tue, 2005-04-05 at 08:06 -0400, Ignacio Vazquez-Abrams wrote:
From http://fedoraproject.org/wiki/Extras_2fFC4Status:
"gpredict (i386, x86_64) - gnome-vfs-devel - buildreq couldn't be installed"
Yes, why is that anyways? I tried to hunt down a reason in the mailing list archives but couldn't find one.
I think it was removed around March 7 (notting mailed me as I was the maintainer of the package) though the buildsys mails for some reason don't reveal this. Sounds like a good candidate for Extras if someone wants to pick it up.
Good Luck, David
On Apr 5, 2005 10:51 AM, David Zeuthen david@fubar.dk wrote:
I think it was removed around March 7 (notting mailed me as I was the maintainer of the package) though the buildsys mails for some reason don't reveal this. Sounds like a good candidate for Extras if someone wants to pick it up.
Hmm.. this is a problem. Right now the build reports are the only way community is being made aware of packages that are being removed. Rawhide is of course rawhide.. so i'm fully aware that this reporting is going to break on occasion. But 'we' need as accurate a list of dropped packages as possible communicated so the community can act in a timely fashion to replace these packages in extras before the next core release if there is interest.
So... assuming the build report system blows up from time to time and removals from rawhide go unreported to the community. What is the best way to periodicly go back and check to make sure the community gets a reasonable headsup about all removals? Periodically being open to reasonable intepretation.
-jef
So... assuming the build report system blows up from time to time and removals from rawhide go unreported to the community. What is the best way to periodicly go back and check to make sure the community gets a reasonable headsup about all removals? Periodically being open to reasonable intepretation.
go through two lists of each releases srpms.
then run: for pkg in *.src.rpm do rpm -qp --qf "%{name}" $pkg > somefile done
and then take the two files you made for each dir of srpms and sort them then:
diff -u file1 file2
and look for the '-'
:)
-sv
On Apr 5, 2005 11:12 AM, seth vidal skvidal@phy.duke.edu wrote:
go through two lists of each releases srpms.
uhm.. the easiest way to do this.. is to keep two whole trees of rawhide src.rpms on disk locally.. so i can do a loop over rpm -qp --qf?
Couldn't i do something similar just with 2 versions of the rawhide metadata cached locally... with repoquery.. assuming the newest yum fixes whatever issues that was keeping repoquery from working last time i tried it?
-jef"If most mirrors dont even cache two rawhide trees across all arches....im sure as hell not gonna do that on my pissy little home network connection"spaleta
On Tue, 2005-04-05 at 11:24 -0400, Jeff Spaleta wrote:
On Apr 5, 2005 11:12 AM, seth vidal skvidal@phy.duke.edu wrote:
go through two lists of each releases srpms.
uhm.. the easiest way to do this.. is to keep two whole trees of rawhide src.rpms on disk locally.. so i can do a loop over rpm -qp --qf?
Couldn't i do something similar just with 2 versions of the rawhide metadata cached locally... with repoquery..
Basically .. why not. The problem ATM is that repoquery uses yum's cache and config so there's no direct, easy way to specify an arbitrary metadata set for purposes like this. On my todo-list though...
assuming the newest yum fixes whatever issues that was keeping repoquery from working last time i tried it?
I don't remember seeing a bug report about it :) Anyway, the current repoquery from yum-utils (or from laiskiainen.org, they're the same) should work just fine with yum 2.3.2, if not, let me know.
- Panu -
On Apr 5, 2005 11:37 AM, Panu Matilainen pmatilai@welho.com wrote:
I don't remember seeing a bug report about it :)
ah crap.. i was confused... repoclosure was the thing that wasnt working for me last time i tried....
Basically .. why not. The problem ATM is that repoquery uses yum's cache and config so there's no direct, easy way to specify an arbitrary metadata set for purposes like this. On my todo-list though...
well no EASY way... but what if i was sneaky and had 2 different yum configurations or something? Any amount of script/configuration file magic is going be far preferable to having to cache all of rawhide locally. The goal is to check to make sure we all have an accurate picture of which packages have been dropped every "reasonably useful period of time" or so days.
-jef"repothis repothat"spaleta
On Tue, 2005-04-05 at 12:02 -0400, Jeff Spaleta wrote:
On Apr 5, 2005 11:37 AM, Panu Matilainen pmatilai@welho.com wrote:
I don't remember seeing a bug report about it :)
ah crap.. i was confused... repoclosure was the thing that wasnt working for me last time i tried....
Basically .. why not. The problem ATM is that repoquery uses yum's cache and config so there's no direct, easy way to specify an arbitrary metadata set for purposes like this. On my todo-list though...
well no EASY way... but what if i was sneaky and had 2 different yum configurations or something? Any amount of script/configuration file magic is going be far preferable to having to cache all of rawhide locally. The goal is to check to make sure we all have an accurate picture of which packages have been dropped every "reasonably useful period of time" or so days.
Well .. just for the purpose of seeing what packages have been added and what removed repoquery + a complex yum-setup with various config files might be a bit of an overkill. Here's something that'll give you a diff of added and removed packages from two local repodata directories: http://laiskiainen.org/yum/utils/repodiff.py
A test with fc3 -> current devel tree appears to give sane results (see below). Note that this will show package reorganizations like splitting packages to -devel etc pieces, to get *real* removals and additions you'd have to compare src.rpm names. Easily fixable if you want it that way...
- Panu -
./repodiff.py /var/www/html/fedora/3/i386 /var/www/html/fedora/devel/ | grep -v debuginfo
New packages: system-config-lvm - 0.9.22-1.0.noarch gcc-gfortran - 4.0.0-0.40.i386 libgcj-src - 4.0.0-0.40.i386 linuxthreads-devel - 2.3.4-21.i686 device-mapper-multipath - 0.4.4-0.pre8.0.i386 setools-devel - 2.0.0-2.i386 openoffice.org-core - 1:1.9.89-3.i386 openoffice.org-pyuno - 1:1.9.89-3.i386 openoffice.org-writer - 1:1.9.89-3.i386 openoffice.org-calc - 1:1.9.89-3.i386 openoffice.org-draw - 1:1.9.89-3.i386 openoffice.org-impress - 1:1.9.89-3.i386 openoffice.org-math - 1:1.9.89-3.i386 openoffice.org-graphicfilter - 1:1.9.89-3.i386 openoffice.org-xsltfilter - 1:1.9.89-3.i386 openoffice.org-javafilter - 1:1.9.89-3.i386 openoffice.org-testtools - 1:1.9.89-3.i386 openoffice.org-langpack-af_ZA - 1:1.9.89-3.i386 openoffice.org-langpack-ar - 1:1.9.89-3.i386 openoffice.org-langpack-bg_BG - 1:1.9.89-3.i386 openoffice.org-langpack-ca_ES - 1:1.9.89-3.i386 openoffice.org-langpack-cs_CZ - 1:1.9.89-3.i386 openoffice.org-langpack-cy_GB - 1:1.9.89-3.i386 openoffice.org-langpack-da_DK - 1:1.9.89-3.i386 openoffice.org-langpack-de - 1:1.9.89-3.i386 openoffice.org-langpack-el_GR - 1:1.9.89-3.i386 openoffice.org-langpack-es - 1:1.9.89-3.i386 openoffice.org-langpack-et_EE - 1:1.9.89-3.i386 openoffice.org-langpack-eu_ES - 1:1.9.89-3.i386 openoffice.org-langpack-fi_FI - 1:1.9.89-3.i386 openoffice.org-langpack-fr - 1:1.9.89-3.i386 openoffice.org-langpack-gl_ES - 1:1.9.89-3.i386 openoffice.org-langpack-he_IL - 1:1.9.89-3.i386 openoffice.org-langpack-hi_IN - 1:1.9.89-3.i386 openoffice.org-langpack-hu_HU - 1:1.9.89-3.i386 openoffice.org-langpack-it - 1:1.9.89-3.i386 openoffice.org-langpack-ja_JP - 1:1.9.89-3.i386 openoffice.org-langpack-kn_IN - 1:1.9.89-3.i386 openoffice.org-langpack-ko_KR - 1:1.9.89-3.i386 openoffice.org-langpack-lt_LT - 1:1.9.89-3.i386 openoffice.org-langpack-ms_MY - 1:1.9.89-3.i386 openoffice.org-langpack-nb_NO - 1:1.9.89-3.i386 openoffice.org-langpack-nl - 1:1.9.89-3.i386 openoffice.org-langpack-nn_NO - 1:1.9.89-3.i386 openoffice.org-langpack-pl_PL - 1:1.9.89-3.i386 openoffice.org-langpack-pt_PT - 1:1.9.89-3.i386 openoffice.org-langpack-pt_BR - 1:1.9.89-3.i386 openoffice.org-langpack-ru - 1:1.9.89-3.i386 openoffice.org-langpack-sk_SK - 1:1.9.89-3.i386 openoffice.org-langpack-sl_SI - 1:1.9.89-3.i386 openoffice.org-langpack-sv - 1:1.9.89-3.i386 openoffice.org-langpack-th_TH - 1:1.9.89-3.i386 openoffice.org-langpack-tr_TR - 1:1.9.89-3.i386 openoffice.org-langpack-zh_CN - 1:1.9.89-3.i386 openoffice.org-langpack-zh_TW - 1:1.9.89-3.i386 openoffice.org-langpack-zu_ZA - 1:1.9.89-3.i386 eclipse-ecj - 1:3.1.0_fc-0.M5.17.i386 eclipse-platform - 1:3.1.0_fc-0.M5.17.i386 eclipse-platform-devel - 1:3.1.0_fc-0.M5.17.i386 eclipse-jdt - 1:3.1.0_fc-0.M5.17.i386 eclipse-jdt-devel - 1:3.1.0_fc-0.M5.17.i386 eclipse-pde - 1:3.1.0_fc-0.M5.17.i386 eclipse-pde-devel - 1:3.1.0_fc-0.M5.17.i386 libswt3-gtk2 - 1:3.1.0_fc-0.M5.17.i386 kernel-smp-devel - 2.6.11-1.1226_FC4.i686 kernel-xen0 - 2.6.11-1.1226_FC4.i686 kernel-xen0-devel - 2.6.11-1.1226_FC4.i686 kernel-xenU - 2.6.11-1.1226_FC4.i686 kernel-xenU-devel - 2.6.11-1.1226_FC4.i686 kernel-devel - 2.6.11-1.1226_FC4.i586 eclipse-cdt - 1:3.0.0_fc-0.M5.3.i386 openswan-doc - 2.3.0-6.i386 sqlite - 3.1.2-2.i386 sqlite-devel - 3.1.2-2.i386 NetworkManager-devel - 0.4-6.cvs20050404.i386 NetworkManager-glib - 0.4-6.cvs20050404.i386 python-elementtree - 1.2.6-4.i386 eclipse-changelog - 1:2.0.1_fc-19.i386 eclipse-bugzilla - 1:0.1.0_fc-9.i386 iiimf-qt - 1:12.1.1-11.svn2435.i386 php-soap - 5.0.4-2.i386 php-xml - 5.0.4-2.i386 xen - 2-20050403.i386 libgconf-java - 2.10.0-1.i386 libgtk-java - 2.6.1.1-1.i386 audit-libs - 0.6.10-1.i386 audit-libs-devel - 0.6.10-1.i386 java-1.4.2-gcj-compat-src - 1.4.2.0-40jpp_14rh.i386 cups-lpd - 1:1.1.23-15.i386 gnome-bluetooth-libs - 0.5.1-12.i386 gnome-bluetooth-devel - 0.5.1-12.i386 totem-devel - 1.0.1-1.i386 OpenIPMI - 1.4.11-5.i386 OpenIPMI-devel - 1.4.11-5.i386 openhpi - 2.0.3-2.i386 openhpi-devel - 2.0.3-2.i386 gnopernicus-devel - 0.10.5-1.i386 libgail-gnome-devel - 1.1.0-5.i386 planner-devel - 0.13-2.i386 gnome-media-devel - 2.10.0-2.i386 cryptsetup-luks - 1.0-1.i386 gnome-python2-extras - 2.10.0-2.1.i386 gnome-python2-gtksourceview - 2.10.0-2.1.i386 gnome-python2-libwnck - 2.10.0-2.1.i386 gnome-python2-libgtop2 - 2.10.0-2.1.i386 gnome-python2-libegg - 2.10.0-2.1.i386 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 gnome-python2-gtkspell - 2.10.0-2.1.i386 gnome-python2-gtkmozembed - 2.10.0-2.1.i386 gnome-menus - 2.10.1-1.i386 gnome-menus-devel - 2.10.1-1.i386 xscreensaver-base - 1:4.21-1.i386 xscreensaver-extras - 1:4.21-1.i386 xscreensaver-gl-extras - 1:4.21-1.i386 rdoc - 1.8.2-6.i386 ri - 1.8.2-6.i386 kde-i18n-Bengali - 1:3.4.0-1.noarch kde-i18n-Hindi - 1:3.4.0-1.noarch kde-i18n-Punjabi - 1:3.4.0-1.noarch kde-i18n-Tamil - 1:3.4.0-1.noarch jsch - 0.1.17-2jpp_1fc.noarch jsch-javadoc - 0.1.17-2jpp_1fc.noarch jsch-demo - 0.1.17-2jpp_1fc.noarch jzlib - 1.0.5-2jpp_1fc.noarch jzlib-javadoc - 1.0.5-2jpp_1fc.noarch jzlib-demo - 1.0.5-2jpp_1fc.noarch gnome-doc-utils - 0.1.3-1.noarch jessie - 1.0.0-3.noarch latex2html - 2002.2.1-1.noarch fonts-gujarati - 1.9-2.noarch fonts-hindi - 1.9-2.noarch fonts-punjabi - 1.9-2.noarch fonts-tamil - 1.9-2.noarch openssl097a - 0.9.7a-2.i386 kdeaccessibility - 1:3.4.0-1.i386 syslinux-devel - 3.07-2.i386 libtool-ltdl - 1.5.14.multilib2-6.i386 libtool-ltdl-devel - 1.5.14.multilib2-6.i386 gjdoc - 0.7.3-1.i386 gamin-python - 0.0.26-1.i386 bison-devel - 2.0-5.i386 tomcat5 - 5.0.30-1jpp_2fc.noarch tomcat5-webapps - 5.0.30-1jpp_2fc.noarch tomcat5-admin-webapps - 5.0.30-1jpp_2fc.noarch evince - 0.1.9-1.i386 mx4j - 1:2.1.0-1jpp_2fc.noarch mx4j-javadoc - 1:2.1.0-1jpp_2fc.noarch mx4j-manual - 1:2.1.0-1jpp_2fc.noarch poppler - 0.1.2-1.i386 poppler-devel - 0.1.2-1.i386 libdbi-drivers - 0.7.1-2.i386 python-sqlite - 1.1.6-1.i386 bind-libbind-devel - 24:9.3.1-1_FC4.i386 bind-sdb - 24:9.3.1-1_FC4.i386 python-urlgrabber - 2.9.6-1.noarch compat-libstdc++-296 - 2.96-132.fc4.i386 compat-libgcc-296 - 2.96-132.fc4.i386 compat-gcc-32 - 3.2.3-47.fc4.i386 compat-gcc-32-c++ - 3.2.3-47.fc4.i386 compat-libstdc++-33 - 3.2.3-47.fc4.i386 compat-gcc-32-g77 - 3.2.3-47.fc4.i386 compat-libf2c-32 - 3.2.3-47.fc4.i386 texi2html - 1.76-2.noarch xmlsec1-gnutls - 1.2.7-4.i386 xmlsec1-gnutls-devel - 1.2.7-4.i386 aqhbci - 1.0.2beta-2.i386 aqhbci-devel - 1.0.2beta-2.i386 aqbanking - 1.0.4beta-2.i386 aqbanking-devel - 1.0.4beta-2.i386 jakarta-commons-modeler - 1.1-3jpp_1fc.noarch jakarta-commons-modeler-javadoc - 1.1-3jpp_1fc.noarch mysqlclient10 - 3.23.58-5.i386 mysqlclient10-devel - 3.23.58-5.i386 libglade-java - 2.9.92-1.i386 eclipse-pydev - 1:0.9.0_fc-4.i386 libgnome-java - 2.9.92-1.i386 ipv6calc - 0.48-3.i386 python-twisted - 1.3.0-4.i386 dmidecode - 1:2.6-1.13.i386 libieee1284-python - 0.2.9-2.i386 dcraw - 0.0.20050227-1.i386 linux-atm - 2.5.0-0.20050118.2.i386 linux-atm-libs - 2.5.0-0.20050118.2.i386 linux-atm-libs-devel - 2.5.0-0.20050118.2.i386 compat-readline43 - 4.3-2.i386 ksh - 20050202-1.i386 lksctp-tools - 1.0.2-5.i386 lksctp-tools-devel - 1.0.2-5.i386 lksctp-tools-doc - 1.0.2-5.i386 gwenhywfar - 1.7.2-2.i386 gwenhywfar-devel - 1.7.2-2.i386 x86info - 1:1.13-1.9.i386 smartmontools - 1:5.33-1.5.i386 rng-utils - 1:2.0-1.5.i386 readahead - 1:1.0-1.7.i386 microcode_ctl - 1:1.11-1.21.i386 longrun - 1:0.9-1.8.i386 irqbalance - 1:1.12-1.18.i386 hardlink - 1:1.0-1.11.i386 cpuspeed - 1:1.2.1-1.19.i386 cpufreq-utils - 1:0.2-1.1.12.i386 VFlib2-xtools - 2.25.6-28.i386 fonts-chinese - 2.15-1.noarch python-numeric - 23.7-2.i386 fonts-korean - 1.0.11-2.noarch fonts-japanese - 0.20050222-2.noarch struts11 - 1.1-1jpp_2fc.noarch struts11-manual - 1.1-1jpp_2fc.noarch struts11-javadoc - 1.1-1jpp_2fc.noarch struts11-webapps-tomcat5 - 1.1-1jpp_2fc.noarch ldapjdk - 4.17-1jpp_2fc.noarch ldapjdk-javadoc - 4.17-1jpp_2fc.noarch lvm2-cluster - 2.00.29-1.22.FC4.i386 puretls - 0.9-0.b4.1jpp_2fc.noarch puretls-javadoc - 0.9-0.b4.1jpp_2fc.noarch puretls-demo - 0.9-0.b4.1jpp_2fc.noarch gnu.getopt - 1.0.9-4jpp_1fc.noarch gnu.getopt-javadoc - 1.0.9-4jpp_1fc.noarch cryptix-asn1 - 20011119-4jpp_1fc.noarch cryptix-asn1-javadoc - 20011119-4jpp_1fc.noarch cryptix - 3.2.0-4jpp_1fc.noarch cryptix-javadoc - 3.2.0-4jpp_1fc.noarch jakarta-commons-daemon - 1:1.0-2jpp_1fc.noarch jakarta-commons-daemon-javadoc - 1:1.0-2jpp_1fc.noarch jakarta-commons-launcher - 0.9-3jpp_1fc.noarch jakarta-commons-launcher-javadoc - 0.9-3jpp_1fc.noarch jakarta-commons-el - 1.0-2jpp_1fc.noarch jakarta-commons-el-javadoc - 1.0-2jpp_1fc.noarch jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch jakarta-taglibs-standard-javadoc - 1.1.1-4jpp_1fc.noarch jakarta-commons-dbcp - 1.2.1-3jpp_1fc.noarch jakarta-commons-dbcp-javadoc - 1.2.1-3jpp_1fc.noarch jakarta-commons-pool - 1.2-2jpp_1fc.noarch jakarta-commons-pool-javadoc - 1.2-2jpp_1fc.noarch jakarta-commons-lang - 2.0-2jpp_1fc.noarch jakarta-commons-lang-javadoc - 2.0-2jpp_1fc.noarch jakarta-commons-validator - 1.1.3-1jpp_1fc.noarch jakarta-commons-validator-javadoc - 1.1.3-1jpp_1fc.noarch jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch jakarta-commons-fileupload-javadoc - 1:1.0-3jpp_1fc.noarch jakarta-commons-digester - 1.6-2jpp_1fc.noarch jakarta-commons-digester-javadoc - 1.6-2jpp_1fc.noarch jakarta-commons-beanutils - 1.7.0-1jpp_1fc.noarch jakarta-commons-beanutils-javadoc - 1.7.0-1jpp_1fc.noarch ant - 1.6.2-3jpp_2fc.noarch ant-antlr - 1.6.2-3jpp_2fc.noarch ant-apache-resolver - 1.6.2-3jpp_2fc.noarch ant-commons-logging - 1.6.2-3jpp_2fc.noarch ant-apache-bcel - 1.6.2-3jpp_2fc.noarch ant-apache-log4j - 1.6.2-3jpp_2fc.noarch ant-apache-oro - 1.6.2-3jpp_2fc.noarch ant-apache-regexp - 1.6.2-3jpp_2fc.noarch ant-javamail - 1.6.2-3jpp_2fc.noarch ant-jdepend - 1.6.2-3jpp_2fc.noarch ant-jmf - 1.6.2-3jpp_2fc.noarch ant-junit - 1.6.2-3jpp_2fc.noarch ant-nodeps - 1.6.2-3jpp_2fc.noarch ant-swing - 1.6.2-3jpp_2fc.noarch ant-trax - 1.6.2-3jpp_2fc.noarch ant-scripts - 1.6.2-3jpp_2fc.noarch ant-manual - 1.6.2-3jpp_2fc.noarch ant-javadoc - 1.6.2-3jpp_2fc.noarch jakarta-commons-collections - 3.1-1jpp_1fc.noarch jakarta-commons-collections-javadoc - 3.1-1jpp_1fc.noarch xalan-j2 - 2.6.0-2jpp_1fc.noarch xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch xalan-j2-manual - 2.6.0-2jpp_1fc.noarch xalan-j2-javadoc - 2.6.0-2jpp_1fc.noarch xalan-j2-demo - 2.6.0-2jpp_1fc.noarch xerces-j2 - 2.6.2-4jpp_1fc.noarch xerces-j2-javadoc-impl - 2.6.2-4jpp_1fc.noarch xerces-j2-javadoc-apis - 2.6.2-4jpp_1fc.noarch xerces-j2-javadoc-dom3 - 2.6.2-4jpp_1fc.noarch xerces-j2-javadoc-xni - 2.6.2-4jpp_1fc.noarch xerces-j2-javadoc-other - 2.6.2-4jpp_1fc.noarch xerces-j2-demo - 2.6.2-4jpp_1fc.noarch xerces-j2-scripts - 2.6.2-4jpp_1fc.noarch jakarta-commons-logging - 1.0.4-2jpp_1fc.noarch jakarta-commons-logging-javadoc - 1.0.4-2jpp_1fc.noarch avalon-logkit - 1.2-2jpp_4fc.noarch avalon-logkit-javadoc - 1.2-2jpp_4fc.noarch log4j - 1.2.8-7jpp_3fc.noarch log4j-manual - 1.2.8-7jpp_3fc.noarch log4j-javadoc - 1.2.8-7jpp_3fc.noarch xml-commons - 1.0-0.b2.6jpp_5fc.noarch xml-commons-apis - 1.0-0.b2.6jpp_5fc.noarch xml-commons-which - 1.0-0.b2.6jpp_5fc.noarch xml-commons-apis-manual - 1.0-0.b2.6jpp_5fc.noarch xml-commons-apis-javadoc - 1.0-0.b2.6jpp_5fc.noarch xml-commons-which-javadoc - 1.0-0.b2.6jpp_5fc.noarch bcel - 5.1-1jpp_4fc.noarch bcel-javadoc - 5.1-1jpp_4fc.noarch jdepend - 2.6-2jpp_3fc.noarch jdepend-javadoc - 2.6-2jpp_3fc.noarch jdepend-demo - 2.6-2jpp_3fc.noarch regexp - 1.3-1jpp_4fc.noarch regexp-javadoc - 1.3-1jpp_4fc.noarch junit - 3.8.1-3jpp_4fc.noarch junit-manual - 3.8.1-3jpp_4fc.noarch junit-javadoc - 3.8.1-3jpp_4fc.noarch junit-demo - 3.8.1-3jpp_4fc.noarch antlr - 2.7.4-2jpp_1fc.noarch antlr-manual - 2.7.4-2jpp_1fc.noarch antlr-javadoc - 2.7.4-2jpp_1fc.noarch classpathx-mail - 1.0-3jpp_1fc.noarch classpathx-mail-javadoc - 1.0-3jpp_1fc.noarch classpathx-jaf - 1.0-2jpp_3fc.noarch classpathx-jaf-javadoc - 1.0-2jpp_3fc.noarch slib - 3a1-2.noarch avalon-framework - 4.1.4-2jpp_5fc.noarch avalon-framework-manual - 4.1.4-2jpp_5fc.noarch avalon-framework-javadoc - 4.1.4-2jpp_5fc.noarch classpath-inetlib - 1.0-1jpp_1fc.noarch classpath-inetlib-javadoc - 1.0-1jpp_1fc.noarch oro - 2.0.8-1jpp_2fc.noarch oro-javadoc - 2.0.8-1jpp_2fc.noarch gnu-crypto - 2.0.1-1jpp_1fc.noarch gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_1fc.noarch gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_1fc.noarch gnu-crypto-javadoc - 2.0.1-1jpp_1fc.noarch xml-commons-resolver - 1.1-1jpp_4fc.noarch xml-commons-resolver-javadoc - 1.1-1jpp_4fc.noarch servletapi5 - 5.0.18-1jpp_3fc.noarch servletapi5-javadoc - 5.0.18-1jpp_3fc.noarch java_cup - 1:0.10-0.k.1jpp_2fc.noarch java_cup-javadoc - 1:0.10-0.k.1jpp_2fc.noarch java_cup-manual - 1:0.10-0.k.1jpp_2fc.noarch jlex - 1.2.6-1jpp_2fc.noarch jlex-javadoc - 1.2.6-1jpp_2fc.noarch
Removed packages: routed - 0.17-18.i386 kdenetwork-nowlistening - 7:3.3.0-5.i386 nautilus-media - 0.8.1-3.i386 gnuchess - 5.07-4.i386 gda-postgres - 1:1.0.4-3.i386 libsilc-doc - 0.9.12-7.i386 cyrus-imapd - 2.2.6-2.FC3.6.i386 comps - 1:3-0.20041103.i386 namazu-cgi - 2.0.13-3.i386 bonobo - 1.0.22-9.i386 ttfonts-ja - 1.2-36.noarch octave - 6:2.1.57-7.i386 gda-odbc - 1:1.0.4-3.i386 xmms-devel - 1:1.2.10-9.i386 openoffice.org-libs - 1.1.2-10.i386 w3m-el - 1.4.3-2.i386 xfce4-iconbox - 4.0.6-2.i386 lapack - 3.0-25.i386 openhbci-devel - 0.9.17-1.i386 ots - 0.4.2-2.i386 asp2php-gtk - 0.76.18-3.i386 ddskk - 12.2.0-4.noarch desktop-backgrounds-extra - 2.0-26.2.noarch gv - 3.5.8-29.i386 xloadimage - 4.1-32.i386 splint - 3.1.1-4.i386 aiksaurus-devel - 1:1.2.1-2.i386 libxfce4util-devel - 4.0.6-1.i386 libesmtp-devel - 1.0.3r1-2.i386 x3270 - 3.3.2.p1-6.i386 MagicPoint - 1.11b-1.i386 gnome-python2-nautilus - 2.6.0-3.i386 kernel-utils - 1:2.4-13.1.39.i386 fonts-ja - 8.0-16.noarch system-logviewer - 0.9.11-1.noarch ncftp - 2:3.1.8-2.i386 Omni-foomatic - 0.9.1-7.i386 xemacs - 21.4.15-9.i386 apel-xemacs - 10.6-5.noarch dbh - 1:1.0.18-5.i386 wl-common - 2.10.1-4.noarch xfce4-panel - 4.0.6-1.i386 cdecl - 2.5-30.i386 lesstif - 0.93.36-6.i386 x3270-x11 - 3.3.2.p1-6.i386 libgnomedb-devel - 1:1.0.4-3.i386 exim-mon - 4.43-1.i386 aumix - 2.8-9.i386 xfdesktop - 4.0.6-2.i386 cyrus-imapd-devel - 2.2.6-2.FC3.6.i386 balsa - 2.2.4-1.FC3.1.i386 pccts - 1.33mr33-11.i386 libxfce4util - 4.0.6-1.i386 xemacs-info - 21.4.15-9.i386 ttfonts-ko - 1.0.11-32.2.noarch FreeWnn-libs - 1:1.10pl020-5.i386 diskcheck - 2:1.6-2.noarch sylpheed - 0.9.12-1.i386 comsat - 0.17-11.i386 php-domxml - 4.3.9-3.i386 openoffice.org-i18n - 1.1.2-10.i386 libgnomedb - 1:1.0.4-3.i386 xosview - 1.8.2-1.i386 giftrans - 1.12.2-20.i386 bzflag - 1.10.6-2.i386 system-switch-im - 0.1.2-3.noarch FreeWnn - 1:1.10pl020-5.i386 dbh-devel - 1:1.0.18-5.i386 compat-pwdb - 0.62-9.i386 ytalk - 3.1.2-1.i386 gpdf - 2.8.0-5.i386 xfwm4-themes - 4.0.6-2.noarch octave-devel - 6:2.1.57-7.i386 xfwm4 - 4.0.6-1.i386 exim-doc - 4.43-1.i386 gcc4-c++ - 4.0.0-0.8.i386 gnome-vfs-extras - 0.2.0-9.i386 libesmtp - 1.0.3r1-2.i386 ttfonts-zh_TW - 2.11-28.noarch cyrus-imapd-murder - 2.2.6-2.FC3.6.i386 nabi - 0.14-3.i386 openhbci - 0.9.17-1.i386 koffice-devel - 4:1.3.3-1.i386 xmms-flac - 1.1.0-7.i386 dmalloc - 5.3.0-3.i386 miniChinput - 0.0.3-58.i386 compat-gcc-g77 - 8-3.3.4.2.i386 Omni - 0.9.1-7.i386 aiksaurus - 1:1.2.1-2.i386 gnumeric-devel - 1:1.2.13-6.i386 Glide3-devel - 20010520-33.i386 flim - 1.14.7-1.noarch libtool-libs13 - 1.3.5-10.i386 xemacs-el - 21.4.15-9.i386 ttfonts-gu - 1.6-1.noarch exim-sa - 4.43-1.i386 xffm - 4.0.6-1.i386 blas - 3.0-25.i386 cproto - 4.7c-3.i386 namazu - 2.0.13-3.i386 jisksp16-1990 - 0.1-16.noarch w3m-el-common - 1.4.3-2.i386 compat-gcc - 8-3.3.4.2.i386 memprof - 1:0.5.1-5.i386 jed - 0.99.16-6.i386 xmms - 1:1.2.10-9.i386 perl-Cyrus - 2.2.6-2.FC3.6.i386 ttfonts-zh_CN - 2.14-10.noarch cryptsetup - 0.1-4.i386 dbskkd-cdb - 1.01-21.i386 gcc-g77 - 3.4.2-6.fc3.i386 fsh - 1.2-5.i386 xemacs-sumo-info - 20040818-2.noarch libgda - 1:1.0.4-3.i386 compat-libgcj - 8-3.3.4.2.i386 gda-mysql - 1:1.0.4-3.i386 skkinput - 2.06.4-7.i386 libxfcegui4 - 4.0.6-1.i386 iiimf-csconv - 1:12.1-4.i386 libf2c - 3.4.2-6.fc3.i386 xemacs-common - 21.4.15-9.i386 ash - 0.3.8-20.i386 kappa20 - 0.3-15.noarch cdp - 0.33-32.i386 xsnow - 1.42-15.i386 tuxracer - 0.61-28.i386 qmkbootdisk - 8:1.0.2-3.i386 aiksaurus-gtk-devel - 1:1.2.1-2.i386 xmms-skins - 1:1.2.10-9.i386 gnumeric - 1:1.2.13-6.i386 db4-java - 4.2.52-6.i386 gnome-vfs - 1.0.5-21.i386 libtool-libs - 1.5.6-4.i386 mew-xemacs - 3.3-4.i386 xemacs-sumo-el - 20040818-2.noarch aspell-ia - 50:0.50-1.i386 xfce-mcs-manager-devel - 4.0.6-2.i386 xfce-utils - 4.0.6-1.i386 w3m-el-xemacs - 1.4.3-2.i386 kinput2 - v3.1-23.i386 asp2php - 0.76.18-3.i386 xemacs-nox - 21.4.15-9.i386 cyrus-imapd-nntp - 2.2.6-2.FC3.6.i386 ttfonts-ta - 1.6-1.noarch compat-gcc-c++ - 8-3.3.4.2.i386 pan - 1:0.14.2-8.i386 gnome-vfs-devel - 1.0.5-21.i386 wl - 2.10.1-4.noarch xfce4-systray - 4.0.6-2.i386 ttfonts-pa - 1.6-1.noarch xboard - 4.2.7-6.i386 lilo - 21.4.4-26.i386 FreeWnn-devel - 1:1.10pl020-5.i386 gcc4-gfortran - 4.0.0-0.8.i386 libxfcegui4-devel - 4.0.6-1.i386 xfce-mcs-plugins - 4.0.6-2.i386 Glide3 - 20010520-33.i386 xscreensaver - 1:4.18-4.i386 dietlibc - 0.27-4.i386 pdksh - 5.2.14-30.i386 koffice-i18n - 4:1.3.3-1.i386 cyrus-imapd-utils - 2.2.6-2.FC3.6.i386 grip - 1:3.2.0-3.i386 openoffice.org - 1.1.2-10.i386 lesstif-devel - 0.93.36-6.i386 kdetoys - 7:3.3.0-1.i386 bluez-bluefw - 1.0-6.i386 libxfce4mcs - 4.0.6-1.i386 ttfonts-hi - 1.6-1.noarch mew-common - 3.3-4.i386 compat-gcc-objc - 8-3.3.4.2.i386 xcin - 2.5.3.pre3-24.i386 ddskk-xemacs - 12.2.0-4.noarch compat-libstdc++ - 8-3.3.4.2.i386 mew - 3.3-4.i386 gcc4 - 4.0.0-0.8.i386 knm_new - 1.1-16.noarch compat-libstdc++-devel - 8-3.3.4.2.i386 xffm-icons - 1:4.0.6-2.noarch kdeaddons-xmms - 3.3.0-2.i386 tora - 1.3.14.1-2.i386 xfprint - 4.0.6-2.i386 abiword - 1:2.0.12-3.i386 cdlabelgen - 3.0.0-1.noarch compat-libgcj-devel - 8-3.3.4.2.i386 nedit - 5.4-3.i386 koffice - 4:1.3.3-1.i386 Maelstrom - 3.0.6-6.i386 flim-xemacs - 1.14.7-1.noarch exim - 4.43-1.i386 libxfce4mcs-devel - 4.0.6-1.i386 bonobo-devel - 1.0.22-9.i386 ttfonts-bn - 1.6-1.noarch libgda-devel - 1:1.0.4-3.i386 namazu-devel - 2.0.13-3.i386 ftpcopy - 0.6.2-7.i386 wl-xemacs - 2.10.1-4.noarch x3270-text - 3.3.2.p1-6.i386 xfce-mcs-manager - 4.0.6-2.i386 aiksaurus-gtk - 1:1.2.1-2.i386 ggv - 2.8.0-1.i386 openoffice.org-kde - 1.1.2-10.i386 ecj - 2.1.3-5.i386 freeciv - 1.14.2-1.i386 ttfprint - 0.9-13.i386 jisksp14 - 0.1-16.noarch nptl-devel - 2.3.3-74.i686 xemacs-sumo - 20040818-2.noarch compat-gcc-java - 8-3.3.4.2.i386 openssl096b - 0.9.6b-19.i386 ots-devel - 0.4.2-2.i386 rpmdb-fedora - 1:3-0.20041103.i386
On Apr 7, 2005 2:59 PM, Panu Matilainen pmatilai@welho.com wrote:
Well .. just for the purpose of seeing what packages have been added and what removed repoquery + a complex yum-setup with various config files might be a bit of an overkill. Here's something that'll give you a diff of added and removed packages from two local repodata directories: http://laiskiainen.org/yum/utils/repodiff.py
<mr burns>excellent</mr burns>
-jef"trying hard to remember why he asked for this...oh right the thread topic"spaleta
On Tue, 2005-04-05 at 11:24 -0400, Jeff Spaleta wrote:
go through two lists of each releases srpms.
uhm.. the easiest way to do this.. is to keep two whole trees of rawhide src.rpms on disk locally.. so i can do a loop over rpm -qp --qf?
Maybe a regular post of treediff output can happen say once every week; same like the rawhide reports...
(or are the failures in treediff itself?)