12:03 a.m.
Running Fedora 14 x86_64, i was trying to search for a package using
YUM. The search results lists multiple versions [Fc12, Fc13, Fc14] and
different arch [i686 and x86_64], of which i just need it to list
against Fc14 and x86_64. Why is this so, can we prevent this or is this
a bad/undesirable feature in yum.
Stack trace :
-----------------------------------------------------------------------------
[sawrub@sawrub ~]$ yum list available pidgin*
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Available Packages
pidgin.x86_64
2.7.5-1.fc14 updates
pidgin-birthday-reminder.x86_64
1.5-2.fc14 fedora
pidgin-devel.i686
2.7.5-1.fc14 updates
pidgin-devel.x86_64
2.7.5-1.fc14 updates
pidgin-docs.x86_64
2.7.5-1.fc14 updates
pidgin-evolution.x86_64
2.7.5-1.fc14 updates
pidgin-gfire.x86_64
0.9.2-2.fc14 fedora
pidgin-guifications.x86_64
2.16-4.fc12 fedora
pidgin-latex.x86_64
1.4.2-1.fc14 updates
pidgin-libnotify.x86_64
0.14-4.fc14 fedora
pidgin-musictracker.x86_64
0.4.20-3.fc13 fedora
pidgin-otr.x86_64
3.2.0-3.fc12 fedora
pidgin-perl.x86_64
2.7.5-1.fc14 updates
pidgin-privacy-please.x86_64
0.6.3-2.fc14 fedora
pidgin-rhythmbox.x86_64
2.0-5.fc12 fedora
pidgin-sipe.x86_64
1.10.1-1.fc14 fedora
[sawrub@sawrub ~]$
-----------------------------------------------------------------------------
--
Saurabh Sharma
Linux user number: 490644
http://sawrub-blog.blogspot.com/
Open your doors.......It's time to look beyond Windows
1:08 p.m.
Sawrub wrote:
On 11/14/2010 03:23 PM, Michael Schwendt wrote:
> On Sun, 14 Nov 2010 11:33:10 +0530, Sawrub wrote:
>
>> Running Fedora 14 x86_64, i was trying to search for a package using
>> YUM. The search results lists multiple versions [Fc12, Fc13, Fc14] and
>> different arch [i686 and x86_64], of which i just need it to list
>> against Fc14 and x86_64. Why is this so, can we prevent this or is this
>> a bad/undesirable feature in yum.
> Packages, which have not been rebuilt for F-14, may still contain an
> older distribution tag (such as ".fc12") in their package release name.
That was clear that searching for a packages under the repos may list a
package that is not of the same OS version [if its not build for that
version] all i wanted was to know that why are they included in the
results for a different version of OS. Since as i have read that
installing packages like this ['OS version xx' packages under 'OS
version yy' ] should not be encouraged. And since YUM is there to make
package installation easy, practices like this should not be there there.
If the package is in the repository for the release, it is working for the new
release. You are reading something into the name which isn't there, and trying
to call it a problem. Programs which have no known bugs, particularly those in
bash, perl, python, or similar, don't need to be changed.
Oh, and bravo to those who don't change them, "creeping featurism" has
turned
many useful little programs into a complex maintenance nightmare, festooned with
garbage enhancements unrelated to the original purpose. Do we really need the
output of df in csv format (someone offered the code)?
> With the x86_64 arch you can also install and run i686 for
32-bit
> compatibility. Not all i686 packages are available in the Yum repository
> for x86_64, though. Just a subset.
>
Yes that i know, all i wanted to say here is that is it a good practice
to list a package of different arch when the one for the requested is
not available under the default search. Packages of different arch
[except noarch] should only be listed against a special YUM option [like
--enable-different-arch] or be listed under a different head in the
default listing [like --Different Architecture--].
Different release isn't different architecture, i686 is a subset of x86_64, i386
a subset of i686, etc.
If this really bothers you, write a {perl,awk,bash,python,sed} script to produce
the listing you want. By itself it might be useful.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
1:29 p.m.
On 11/25/2010 11:08 AM, Bill Davidsen wrote:
Programs which have no known bugs, particularly those in
bash, perl, python, or similar, don't need to be changed.
Maybe we need a tag, similar to noarch for packages that aren't version
specific. Possibly "nover," for "no version" would do the job. Put
it
in place of F12, or whatever, and people would stop making mountains out
of molehills (or, to quote Tully, "billows in basins") because the
version numbers don't match.
2:03 a.m.
On Sun, 14 Nov 2010 07:50:19 -0500, Lamar wrote:
On Sunday, November 14, 2010 06:29:21 am Sawrub wrote:
> On 11/14/2010 04:07 PM, Michael Schwendt wrote:
> > On Sun, 14 Nov 2010 15:51:44 +0530, Sawrub wrote:
> >> all i wanted was to know that why are they included in the
> >> results for a different version of OS.
> > Because [hopefully] they continue to work and [hopefully] the package
> > maintainer has verified that they still work without a rebuild.
> >
> Or may be the maintainer is no longer interested in re-building.
Then they would be in the orphans list, and they would eventually be dropped if a new
maintainer didn't step up to the plate. At least that's my reading of the
packaging guidelines; Michael is free to correct me, as he's been more closely
involved over the years.
In reality, some maintainers abandon their packages silently. Without
announcing them as orphans. It needs someone else to discover the poor
state a package is in, to notice that bugzilla tickets haven't been
answered, and to start the non-responsive maintainer procedure according
to the guidelines.
6:50 a.m.
On Sunday, November 14, 2010 06:29:21 am Sawrub wrote:
On 11/14/2010 04:07 PM, Michael Schwendt wrote:
> On Sun, 14 Nov 2010 15:51:44 +0530, Sawrub wrote:
>> all i wanted was to know that why are they included in the
>> results for a different version of OS.
> Because [hopefully] they continue to work and [hopefully] the package
> maintainer has verified that they still work without a rebuild.
>
Or may be the maintainer is no longer interested in re-building.
Then they would be in the orphans list, and they would eventually be dropped if a new
maintainer didn't step up to the plate. At least that's my reading of the
packaging guidelines; Michael is free to correct me, as he's been more closely
involved over the years.
If a package from, say, Red Hat Linux 5.2 (not RHEL5, but old-school RHL) were to run
unmodified directly on F14 (don't know any that do, but 5.2 is the oldest dist I still
have running in a production setting (not connected to the Internet!)) then why would a
rebuild be needed?
Ten years ago I was contracted by a company to build RPM's of PostgreSQL 7 for a
number of different distributions. I was pleasantly surprised at how portable (to a
degree) packages for different distribution versions were... even packages for a whole
different distribution can be made portable, to a degree, as long as package names (for
dependencies) are the same, and the versions are fairly close for most required packages.
Essentially, I could take pains to make the dependencies as generic as possible, and I
could install one distribution's package directly on another. Now, since I was being
paid to do this, I did do native builds for all the supported distributions; but for
testing it was fun to cross-install packages.
And I know of several commercial packages that are portable in this way. VMware
Workstation, when it was still distributed as RPM, was like this. CodeWeavers'
CrossOver is still distributed in a distribution-independent RPM. The Fluendo DVD player,
Media Center, and codec packs are distributed in distribution-independent RPM's. And
there are other examples.
So, as Michael said, don't read too much into dist tags; they're there only as a
hint, not as a hard dependency.
6:49 a.m.
On Sun, 14 Nov 2010 16:59:21 +0530, Sawrub wrote:
[F-14 rpms with old dist tags .fc13, .fc12]
Or may be the maintainer is no longer interested in re-building.
True. Packages, which haven't been "touched" for many months, may be an
indication that their maintainer is missing. Even more so, if there are
open bugs and a newer upstream release.
>> Since as i have read that
>> installing packages like this ['OS version xx' packages under 'OS
>> version yy' ] should not be encouraged.
> Where?
>
It was in my early days that i got to know this probably in some list
when i was trying to learn using yum.
Could be misinformation. ;) The .fcXX dist tag in the package release
value has never been mandatory. Packagers can still choose to not add
the corresponding %{?dist} macro to an RPM package spec file. Using
%{?dist} is not 100% safe. It is helpful with some aspects of package
maintenance, but also adds some pitfalls.
4:37 a.m.
On Sun, 14 Nov 2010 15:51:44 +0530, Sawrub wrote:
> Packages, which have not been rebuilt for F-14, may still
contain an
> older distribution tag (such as ".fc12") in their package release name.
That was clear that searching for a packages under the repos may list a
package that is not of the same OS version [if its not build for that
version]
The dist tag in the package name isn't as important as you may think it is.
The packages just haven't been _rebuilt_ for various reasons. First of all,
there hasn't been a mass-rebuild of _all_ packages for F-14, because no
compiler upgrade required/justified doing that. Second, the package's
build dependencies probably haven't changed either. Nowhere is written
that a package built _on_ F-12 would no longer work on F-13 or F-14.
Whether it requires a rebuild depends on several factors. Third, the
packaged software might not have seen an update by its authors either.
all i wanted was to know that why are they included in the
results for a different version of OS.
Because [hopefully] they continue to work and [hopefully] the package
maintainer has verified that they still work without a rebuild.
Since as i have read that
installing packages like this ['OS version xx' packages under 'OS
version yy' ] should not be encouraged.
Where?
And since YUM is there to make
package installation easy, practices like this should not be there there.
Who says that? Do you get any errors when trying to install the packages?
Or when you run the software?
> With the x86_64 arch you can also install and run i686 for
32-bit
> compatibility. Not all i686 packages are available in the Yum repository
> for x86_64, though. Just a subset.
>
Yes that i know, all i wanted to say here is that is it a good practice
to list a package of different arch when the one for the requested is
not available under the default search. Packages of different arch
[except noarch] should only be listed against a special YUM option [like
--enable-different-arch] or be listed under a different head in the
default listing [like --Different Architecture--].
You can configure your Yum to exclude i686 packages, if you don't need
them for anything.
4:21 a.m.
On 11/14/2010 03:23 PM, Michael Schwendt wrote:
On Sun, 14 Nov 2010 11:33:10 +0530, Sawrub wrote:
> Running Fedora 14 x86_64, i was trying to search for a package using
> YUM. The search results lists multiple versions [Fc12, Fc13, Fc14] and
> different arch [i686 and x86_64], of which i just need it to list
> against Fc14 and x86_64. Why is this so, can we prevent this or is this
> a bad/undesirable feature in yum.
Packages, which have not been rebuilt for F-14, may still contain an
older distribution tag (such as ".fc12") in their package release name.
That was clear that searching for a packages under the repos may list a
package that is not of the same OS version [if its not build for that
version] all i wanted was to know that why are they included in the
results for a different version of OS. Since as i have read that
installing packages like this ['OS version xx' packages under 'OS
version yy' ] should not be encouraged. And since YUM is there to make
package installation easy, practices like this should not be there there.
With the x86_64 arch you can also install and run i686 for 32-bit
compatibility. Not all i686 packages are available in the Yum repository
for x86_64, though. Just a subset.
Yes that i know, all i wanted to say here is that is it a good practice
to list a package of different arch when the one for the requested is
not available under the default search. Packages of different arch
[except noarch] should only be listed against a special YUM option [like
--enable-different-arch] or be listed under a different head in the
default listing [like --Different Architecture--].
> Stack trace :
> -----------------------------------------------------------------------------
> [sawrub@sawrub ~]$ yum list available pidgin*
That isn't a stack trace.
My bad, will keep in mind
--
Saurabh Sharma
Linux user number: 490644
http://sawrub-blog.blogspot.com/
Open your doors.......It's time to look beyond Windows
3:53 a.m.
On Sun, 14 Nov 2010 11:33:10 +0530, Sawrub wrote:
Running Fedora 14 x86_64, i was trying to search for a package
using
YUM. The search results lists multiple versions [Fc12, Fc13, Fc14] and
different arch [i686 and x86_64], of which i just need it to list
against Fc14 and x86_64. Why is this so, can we prevent this or is this
a bad/undesirable feature in yum.
Packages, which have not been rebuilt for F-14, may still contain an
older distribution tag (such as ".fc12") in their package release name.
With the x86_64 arch you can also install and run i686 for 32-bit
compatibility. Not all i686 packages are available in the Yum repository
for x86_64, though. Just a subset.
Stack trace :
-----------------------------------------------------------------------------
[sawrub@sawrub ~]$ yum list available pidgin*
That isn't a stack trace.
5:29 a.m.
On 11/14/2010 04:07 PM, Michael Schwendt wrote:
On Sun, 14 Nov 2010 15:51:44 +0530, Sawrub wrote:
>> Packages, which have not been rebuilt for F-14, may still contain an
>> older distribution tag (such as ".fc12") in their package release
name.
> That was clear that searching for a packages under the repos may list a
> package that is not of the same OS version [if its not build for that
> version]
The dist tag in the package name isn't as important as you may think it is.
The packages just haven't been _rebuilt_ for various reasons. First of all,
there hasn't been a mass-rebuild of _all_ packages for F-14, because no
compiler upgrade required/justified doing that. Second, the package's
build dependencies probably haven't changed either. Nowhere is written
that a package built _on_ F-12 would no longer work on F-13 or F-14.
Whether it requires a rebuild depends on several factors. Third, the
packaged software might not have seen an update by its authors either.
> all i wanted was to know that why are they included in the
> results for a different version of OS.
Because [hopefully] they continue to work and [hopefully] the package
maintainer has verified that they still work without a rebuild.
Or may be the maintainer is no longer interested in re-building.
> Since as i have read that
> installing packages like this ['OS version xx' packages under 'OS
> version yy' ] should not be encouraged.
Where?
It was in my early days that i got to know this probably in some list
when i was trying to learn using yum.
> And since YUM is there to make
> package installation easy, practices like this should not be there there.
Who says that? Do you get any errors when trying to install the packages?
Or when you run the software?
No, nothing like that.
>> With the x86_64 arch you can also install and run i686 for
32-bit
>> compatibility. Not all i686 packages are available in the Yum repository
>> for x86_64, though. Just a subset.
>>
> Yes that i know, all i wanted to say here is that is it a good practice
> to list a package of different arch when the one for the requested is
> not available under the default search. Packages of different arch
> [except noarch] should only be listed against a special YUM option [like
> --enable-different-arch] or be listed under a different head in the
> default listing [like --Different Architecture--].
You can configure your Yum to exclude i686 packages, if you don't need
them for anything.
Ok fine, will take a look more deeply into this.
Thanks
--
Saurabh Sharma
Linux user number: 490644
http://sawrub-blog.blogspot.com/
Open your doors.......It's time to look beyond Windows
4913
days inactive
4924
days old
9 comments
5 participants
participants (5)
-
Bill Davidsen -
Joe Zeff -
Lamar Owen -
Michael Schwendt -
Sawrub