Hi,
I installed FC5T3 x86_64 via network using only first isntall CD. I ended up with some packages sort-of duplicated, e.g.
$ rpm -qa |grep kde |sort kdeaddons-3.5.1-1.2 kdeadmin-3.5.1-1.2 kdeartwork-3.5.1-1.2 kdebase-3.5.1-2.2 *1 kdebase-3.5.1-2.2 *1 kdebase-devel-3.5.1-2.2 kdebindings-3.5.1-1.2 kdegames-3.5.1-1.2 kdegraphics-3.5.1-2.1 kdegraphics-devel-3.5.1-2.1 kdelibs-3.5.1-2.2 *2 kdelibs-3.5.1-2.2 *2 kdelibs-devel-3.5.1-2.2 kdemultimedia-3.5.1-1.2 *3 kdemultimedia-3.5.1-1.2 *3 kdenetwork-3.5.1-1.2 kdenetwork-devel-3.5.1-1.2 kdepim-3.5.1-1.2 kdepim-devel-3.5.1-1.2 kdesdk-3.5.1-1.2 kdeutils-3.5.1-1.2 kdeutils-devel-3.5.1-1.2 kdevelop-3.3.1-1.2 lockdev-1.0.1-9.2.1 lockdev-devel-1.0.1-9.2.1 unixODBC-kde-2.2.11-6.2.1 *4 unixODBC-kde-2.2.11-6.2.1 *4
They are not exactly the same, even though versions seem to indicate they are -- see Build Host, Build Date, Size (!), Signature:
$ rpm -qi kdebase Name : kdebase Relocations: (not relocatable) Version : 3.5.1 Vendor: Red Hat, Inc. Release : 2.2 Build Date: Sun 12 Feb 2006 12:12:12 AM GMT Install Date: Wed 22 Feb 2006 02:06:52 AM GMT Build Host: ls20-bc1-14.build.redhat.com Group : User Interface/Desktops Source RPM: kdebase-3.5.1-2.2.src.rpm Size : 60140740 License: GPL Signature : DSA/SHA1, Tue 14 Feb 2006 06:46:47 PM GMT, Key ID da84cbd430c9ecf8 Packager : Red Hat, Inc. http://bugzilla.redhat.com/bugzilla URL : http://www.kde.org Summary : K Desktop Environment - core files Description : Core applications for the K Desktop Environment. Included are: kdm (replacement for xdm), kwin (window manager), konqueror (filemanager, web browser, ftp client, ...), konsole (xterm replacement), kpanel (application starter and desktop pager), kaudio (audio server), kdehelp (viewer for kde help files, info and man pages), kthememgr (system for managing alternate theme packages) plus other KDE components (kcheckpass, kikbd, kscreensaver, kcontrol, kfind, kfontmanager, kmenuedit). Name : kdebase Relocations: (not relocatable) Version : 3.5.1 Vendor: Red Hat, Inc. Release : 2.2 Build Date: Sun 12 Feb 2006 12:52:05 AM GMT Install Date: Wed 22 Feb 2006 02:47:43 AM GMT Build Host: hs20-bc1-1.build.redhat.com Group : User Interface/Desktops Source RPM: kdebase-3.5.1-2.2.src.rpm Size : 55457345 License: GPL Signature : DSA/SHA1, Tue 14 Feb 2006 06:45:44 PM GMT, Key ID da84cbd430c9ecf8 Packager : Red Hat, Inc. http://bugzilla.redhat.com/bugzilla URL : http://www.kde.org Summary : K Desktop Environment - core files Description : Core applications for the K Desktop Environment. Included are: kdm (replacement for xdm), kwin (window manager), konqueror (filemanager, web browser, ftp client, ...), konsole (xterm replacement), kpanel (application starter and desktop pager), kaudio (audio server), kdehelp (viewer for kde help files, info and man pages), kthememgr (system for managing alternate theme packages) plus other KDE components (kcheckpass, kikbd, kscreensaver, kcontrol, kfind, kfontmanager, kmenuedit).
Anyone else seeing this?
Regards, Dariusz
___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
On 02/26/2006 05:21 PM, Dariusz J. Garbowski wrote:
Hi,
I installed FC5T3 x86_64 via network using only first isntall CD. I ended up with some packages sort-of duplicated, e.g.
$ rpm -qa |grep kde |sort kdeaddons-3.5.1-1.2 kdeadmin-3.5.1-1.2 kdeartwork-3.5.1-1.2 kdebase-3.5.1-2.2 *1 kdebase-3.5.1-2.2 *1
[...]
Ok, I figured that one package is 64-bit build and the other 32-bit. I suppose it's intentional?
Regards, Dariusz
___________________________________________________________ NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/
On Sun, 2006-02-26 at 17:26 +0000, Dariusz J. Garbowski wrote:
On 02/26/2006 05:21 PM, Dariusz J. Garbowski wrote:
Hi,
I installed FC5T3 x86_64 via network using only first isntall CD. I ended up with some packages sort-of duplicated, e.g.
$ rpm -qa |grep kde |sort kdeaddons-3.5.1-1.2 kdeadmin-3.5.1-1.2 kdeartwork-3.5.1-1.2 kdebase-3.5.1-2.2 *1 kdebase-3.5.1-2.2 *1
[...]
Ok, I figured that one package is 64-bit build and the other 32-bit. I suppose it's intentional?
yes and you'll find if you run:
yum list installed
that it becomes a lot more apparent.
-sv
On 02/26/2006 05:28 PM, seth vidal wrote:
On Sun, 2006-02-26 at 17:26 +0000, Dariusz J. Garbowski wrote:
On 02/26/2006 05:21 PM, Dariusz J. Garbowski wrote:
Hi,
I installed FC5T3 x86_64 via network using only first isntall CD. I ended up with some packages sort-of duplicated, e.g.
$ rpm -qa |grep kde |sort kdeaddons-3.5.1-1.2 kdeadmin-3.5.1-1.2 kdeartwork-3.5.1-1.2 kdebase-3.5.1-2.2 *1 kdebase-3.5.1-2.2 *1
[...]
Ok, I figured that one package is 64-bit build and the other 32-bit. I suppose it's intentional?
yes and you'll find if you run:
yum list installed
that it becomes a lot more apparent.
That's a nice feature! Thanks, Seth. It's more clear now.
Dariusz
___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Once upon a time Sunday 26 February 2006 11:21 am, Dariusz J. Garbowski wrote:
Hi,
I installed FC5T3 x86_64 via network using only first isntall CD. I ended up with some packages sort-of duplicated, e.g.
try rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}\n" |grep kde|sort you will see that they are the i386 version and the x86_64 this is normal
On 2/26/06, Dennis Gilmore dennis@ausil.us wrote:
Once upon a time Sunday 26 February 2006 11:21 am, Dariusz J. Garbowski wrote:
Hi,
I installed FC5T3 x86_64 via network using only first isntall CD. I ended up with some packages sort-of duplicated, e.g.
try rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}\n" |grep kde|sort you will see that they are the i386 version and the x86_64 this is normal
Why is this not the default queryformat for x86_64? It would cut down on a lot of confusion and noise for those new to the x86_64 platform. And I do not see what it would hurt to make it default in all cases if it complicates things to make it default for only x86_64. It's fairly simple to add this to your .rpmmacros, but the people who will know to do this will already know about the dual-arch stuff.
Jonathan
On Sun, 2006-02-26 at 15:36 -0600, Jonathan Berry wrote:
Why is this not the default queryformat for x86_64? It would cut down on a lot of confusion and noise for those new to the x86_64 platform. And I do not see what it would hurt to make it default in all cases if it complicates things to make it default for only x86_64. It's fairly simple to add this to your .rpmmacros, but the people who will know to do this will already know about the dual-arch stuff.
Because changing the expected output of rpm -q is a bad bad thing. Don't do that. Of course people shouldn't be screen scraping the output or relying on it w/out doing their own --qf for ensured stability, people do anyway, and we'd rather not break all their scripts.
On 2/26/06, Jesse Keating jkeating@j2solutions.net wrote:
On Sun, 2006-02-26 at 15:36 -0600, Jonathan Berry wrote:
Why is this not the default queryformat for x86_64? It would cut down on a lot of confusion and noise for those new to the x86_64 platform. And I do not see what it would hurt to make it default in all cases if it complicates things to make it default for only x86_64. It's fairly simple to add this to your .rpmmacros, but the people who will know to do this will already know about the dual-arch stuff.
Because changing the expected output of rpm -q is a bad bad thing. Don't do that. Of course people shouldn't be screen scraping the output or relying on it w/out doing their own --qf for ensured stability, people do anyway, and we'd rather not break all their scripts.
I see where you are coming from, but on x86_64 you essentially must add the arch into the rpm queryformat, so you could have this issue anyway. Why should we support people if they are not doing the right thing (using -q instead of -qf)? Why should we not fix something because it will break backwards compatibility? OSS seems to do this all the time, eg the kernel or the recent glibc ABI change. Of course, we could debate whether this problem needs fixing, but from my point of view, it does. The default output on x86_64 is ambiguous. I don't intend to be argumentative, and I think backwards compatibility is usually a good thing, but sometimes you just have to break it to improve something. Well, there you have my opinion : ).
Jonathan
Jesse Keating wrote:
On Sun, 2006-02-26 at 15:36 -0600, Jonathan Berry wrote:
Why is this not the default queryformat for x86_64? It would cut down on a lot of confusion and noise for those new to the x86_64 platform. And I do not see what it would hurt to make it default in all cases if it complicates things to make it default for only x86_64. It's fairly simple to add this to your .rpmmacros, but the people who will know to do this will already know about the dual-arch stuff.
Because changing the expected output of rpm -q is a bad bad thing. Don't do that. Of course people shouldn't be screen scraping the output or relying on it w/out doing their own --qf for ensured stability, people do anyway, and we'd rather not break all their scripts.
For FC5 I agree with that of course, since we're nearing the end of the FC5 devel cycle. Once FC6 development begins however, it would be a prime time to make this change to rpm in rawhide so that everyone who relies on the current behaviour will have plenty of time to fix their scripts.
Then, if it appears there are still a lot of broken scripts out there as FC6 nears, we can change it back to the current query results for FC6, and then re-change it for FC7 development.
The end goal being a migration from what it reports now, to what we would like it to report in the future, with plenty of time for people to fix broken scripts that don't formulate their own --qf queries.
This allows forward progress, while minimizing problems, and providing a migration path.
For FC5 I agree with that of course, since we're nearing the end of the FC5 devel cycle. Once FC6 development begins however, it would be a prime time to make this change to rpm in rawhide so that everyone who relies on the current behaviour will have plenty of time to fix their scripts.
Then, if it appears there are still a lot of broken scripts out there as FC6 nears, we can change it back to the current query results for FC6, and then re-change it for FC7 development.
The end goal being a migration from what it reports now, to what we would like it to report in the future, with plenty of time for people to fix broken scripts that don't formulate their own --qf queries.
This allows forward progress, while minimizing problems, and providing a migration path.
Alternatively, we could discourage the use of rpm as a command itself and push people toward using repoquery. repoquery acts on local rpmdb's as much as repositories.
and repoquery's default format is: name-epoch:ver-rel.arch
-sv
On 02/27/2006 01:19 PM, seth vidal wrote:
For FC5 I agree with that of course, since we're nearing the end of the FC5 devel cycle. Once FC6 development begins however, it would be a prime time to make this change to rpm in rawhide so that everyone who relies on the current behaviour will have plenty of time to fix their scripts.
Then, if it appears there are still a lot of broken scripts out there as FC6 nears, we can change it back to the current query results for FC6, and then re-change it for FC7 development.
The end goal being a migration from what it reports now, to what we would like it to report in the future, with plenty of time for people to fix broken scripts that don't formulate their own --qf queries.
This allows forward progress, while minimizing problems, and providing a migration path.
Alternatively, we could discourage the use of rpm as a command itself and push people toward using repoquery. repoquery acts on local rpmdb's as much as repositories.
and repoquery's default format is: name-epoch:ver-rel.arch
Additionally a note in Release Notes in x86_64 specific part about it could go a long way as to prevent some confusion. One short paragraph that the x86_64 release contains some packages in two versions 32- and 64-bit and eventually how to query for them.
It will not prevent all reports about duplicate packages but at least limit their number and also provide some educational/useful information.
Dariusz
___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Dariusz J. Garbowski wrote:
Alternatively, we could discourage the use of rpm as a command itself and push people toward using repoquery. repoquery acts on local rpmdb's as much as repositories.
and repoquery's default format is: name-epoch:ver-rel.arch
Additionally a note in Release Notes in x86_64 specific part about it could go a long way as to prevent some confusion. One short paragraph that the x86_64 release contains some packages in two versions 32- and 64-bit and eventually how to query for them.
I have a added a note that mentions this and recommends using repoquery instead along with the rpm command to list architecture. The release notes for FC5 might be already frozen for translation though. If so it will be available in the updated web errata published.
http://fedoraproject.org/wiki/Docs/Beats/ArchSpecific/x86_64
Hi
Mike A. Harris wrote:
For FC5 I agree with that of course, since we're nearing the end of the FC5 devel cycle. Once FC6 development begins however, it would be a prime time to make this change to rpm in rawhide so that everyone who relies on the current behaviour will have plenty of time to fix their scripts.
Then, if it appears there are still a lot of broken scripts out there as FC6 nears, we can change it back to the current query results for FC6, and then re-change it for FC7 development.
Filed a RFE based on this suggestion. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183202
On Sun, Feb 26, 2006 at 03:36:40PM -0600, Jonathan Berry wrote:
On 2/26/06, Dennis Gilmore dennis@ausil.us wrote:
try rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}\n" |grep kde|sort you will see that they are the i386 version and the x86_64 this is normal
Why is this not the default queryformat for x86_64?
It would be really nasty to make an output of 'rpm -qa' architecture dependent. OTOH /etc/cron.daily/rpm does something pretty close to the above so it is enough to grep through /var/log/rpmpkgs (and you can run /etc/cron.daily/rpm yourself if logs are not current yet).
Michal
-
Dariusz J. Garbowski -
Dennis Gilmore -
Jesse Keating -
Jonathan Berry -
Michal Jaegermann -
Mike A. Harris -
Rahul Sundaram -
seth vidal