On 12/18/2008 02:45 PM, Karanbir Singh wrote:

Manuel Wolfshant wrote:

...

I've just noticed that there is a small typo in %description for yum-basearchonly. Quoting the relevant part only: Description: this plugin makes Yum only install basearch packages on multiarch systems. If you type 'yum install : foo' on a x68_64 system, only 'foo-x.y.x86_46.rpm' is installed.

note that x68_64 != x86_46 (and neither one is correct.) This is also valid for 1.1.10-9.el5.centos (from Base) and for 1.1.14-0_beta_15_2.el5.centos (testing)

And I think that the license (GPL) is also not correct, all other plugins coming from the same source seem to be GPLv2+

Sounds like something for upstream really. Otherwise we can make the change locally as well.

Bz.r.c: https://bugzilla.redhat.com/show_bug.cgi?id=477079

license is correct in yum-utils-1.1.16-13; for reasons that I have not identified yet, latest version that my yum info sees is still 1.1.14 [commands below performed after yum clean all):

[wolfy@wolfy2 tmp]$ yum info yum-basearchonly --enablerepo=testing Loaded plugins: allowdowngrade, downloadonly, fastestmirror, merge-conf Available Packages Name : yum-basearchonly Arch : noarch Version : 1.1.14 Release : 0_beta_15_2.el5.centos Size : 10 k Repo : testing Summary : Yum plugin to let Yum install only basearch packages. URL : http://linux.duke.edu/yum/download/yum-utils/ License : GPL Description: this plugin makes Yum only install basearch packages on multiarch systems. If you type 'yum install : foo' on a x68_64 system, only 'foo-x.y.x86_46.rpm' is installed. If you want to install the : foo-x.y.i386.rpm, you have to type 'yum install foo.i386'. The plugin only works with 'yum : install'.

[wolfy@wolfy2 tmp]$ tail -7 /etc/yum.repos.d/CentOS-Base.repo

#packages in testing [testing] name=CentOS-$releasever - Testing baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/ gpgcheck=1 enabled=1 gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing

On Mon, 2008-12-22 at 12:29 -0800, Akemi Yagi wrote:

On Fri, Dec 12, 2008 at 4:56 PM, Karanbir Singh mail-lists@karan.org wrote:

...

The following packages have been updated in the testing repo : ./5/testing/SRPMS/yum-utils-1.1.16-13.el5.centos.src.rpm ./5/testing/SRPMS/yum-3.2.19-18.el5.centos.src.rpm

...

test these on non-production machines only for now. And all feedback is appreciated.

yum-3.2.19-18 produces the following errors if run with the "--enablerepo=atrpms" option.

It goes back to working again, if you use the older yum version? Does it then fail again if you re-use the newer yum?

[...]

File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 470, in _sql_pkgKey2po pkg = self._packageByKey(repo, ob['pkgKey']) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 413, in _packageByKey po = self.pc(repo, cur.fetchone()) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 68, in __init__ self._read_db_obj(db_obj) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 94, in _read_db_obj setattr(self, item, _share_data(db_obj[item])) TypeError: unsubscriptable object

This is more understandable upstream by:

http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=3120676a73219b018d317...

...which gives a "nice" message. There is also a change to yum-metadata-parser, which should work around the problem in atrpms. The short term. fixes are:

1. Don't use atrpms.

2. Use "yum clean metadata"

On Mon, Dec 22, 2008 at 10:34:55PM +0100, Dag Wieers wrote:

On Mon, 22 Dec 2008, James Antill wrote:

...

On Mon, 2008-12-22 at 12:29 -0800, Akemi Yagi wrote:

...

On Fri, Dec 12, 2008 at 4:56 PM, Karanbir Singh mail-lists@karan.org wrote:

[...]

...

File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 470, in _sql_pkgKey2po pkg = self._packageByKey(repo, ob['pkgKey']) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 413, in _packageByKey po = self.pc(repo, cur.fetchone()) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 68, in __init__ self._read_db_obj(db_obj) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 94, in _read_db_obj setattr(self, item, _share_data(db_obj[item])) TypeError: unsubscriptable object

This is more understandable upstream by:

http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=3120676a73219b018d317...

...which gives a "nice" message. There is also a change to yum-metadata-parser, which should work around the problem in atrpms. The short term. fixes are:

1. Don't use atrpms.

2. Use "yum clean metadata"

Can you be a little bit more specific ? Is there a thread describing the issue ? Is there going to be a real fix for it ?

I really don't feel good with this patch. The error does not indicate to a user that a "yum clean metadata" resolves their problem.

If we are going to have all our users that use atrpms go through this by default, then I think we should avoid it at all cost.

I also don't understand the patch mentioned above. What at ATrpms upsets the new yum that way? If it's something I can fix on my end, I'd gladly do so, but I'm just using plain createrepo (and this seems to work with the yum version in question with other distros).

On Mon, 22 Dec 2008, James Antill wrote:

On Mon, 2008-12-22 at 23:57 +0200, Axel Thimm wrote:

...

On Mon, Dec 22, 2008 at 10:34:55PM +0100, Dag Wieers wrote:

...

Can you be a little bit more specific ? Is there a thread describing the issue ? Is there going to be a real fix for it ?

The BZ I can easily find is RH 465898:

[https://bugzilla.redhat.com/show_bug.cgi?id=465898 TypeError: 'NoneType' object is unsubscriptable error in sqlitesack.py:94:_read_db_obj (pkgId can't be found)]

...although I'm sure we discussed something with You or Axel at one point about multiple pkgId's in one repo.

It wasn't me. How can multiple pkgId's be in one repo ?

From the bugzilla entries, I found this excerpt:

Ok, everytime I've seen this bug now it's someone using an atrpms repo. It's possible they are doing something weird with multiple packages with the same pkgId, combined with their desire to ship only .xml metadata might produce these kinds of errors.

I can add that I would be happy to use the latest and greatest createrepo if those newer versions would work with older distributions (namely, older python versions) and if they can produce metadata that works with older yum/apt releases as well. (Also on RHEL2.1 and RH7.3 systems)

In the past that was not always the case and we are not all using the latest Fedora for creating and hosting repo metadata.

...

I also don't understand the patch mentioned above. What at ATrpms upsets the new yum that way?

The yum patch is to stop the backtraces, and give a warning to the user that the repo. is currently broken.

Well, I wonder why you think that the warning is better than the backtrace if the user does not understand what the warning means or who they should talk to and yum would still fail to work as they expect.

On Mon, 22 Dec 2008, James Antill wrote:

On Tue, 2008-12-23 at 00:04 +0100, Dag Wieers wrote:

...

I can add that I would be happy to use the latest and greatest createrepo if those newer versions would work with older distributions (namely, older python versions) and if they can produce metadata that works with older yum/apt releases as well. (Also on RHEL2.1 and RH7.3 systems)

AFAIK noone has any plans to backport any version of createrepo to work with RHEL-2.1 or older.

There was (and still is on RHEL5) a createrepo with the -n option of which the _only_ purpose is to support those distributions. Now Seth already made clear that the support was broken in later releases (but the option still worked) and he had no interest to revive it. So I have not tried out any new versions (and so no sqlite metadata...).

But it was unfortunate that when repomd was designed, it was not designed for supporting a distribution that was still more than 4 years from being unsupported by Red Hat. And that despite our needs, the repomd XML format was nog slightly changed (making Epoch tag optional). And that to me is worrysome.

(repoview still has a bug, and my patch to support it was never applied)

Imagine creating a createrepo release *now* that would no longer support the RPM quirks that ship with RHEL4. The lack of such backward compatibility is what I have seen many times for basic infrastructure (like eg. yum) on and on because development is only targetted to Fedora.

There is a nebulous plan to create a simple script² which can be used on "older" releases, which will take the normal createrepo (without -d) and just add the .sqlite files in. How far back it'll go isn't clear yet (having not been written), but I'd guess that without help from you RHEL-2.1 is probably not going to be tested.

Well, I have send in bugreports and patches in the past with the only result of having seen the bugreports been deleted (yes, not just closed) and either no or little response that was helpful.

So if I sound a bit harsh on things, it's because there's some history (and lost time/effort) attached :)

On Tue, 2008-12-23 at 08:12 +0200, Axel Thimm wrote:

On Mon, Dec 22, 2008 at 05:48:22PM -0500, James Antill wrote:

...

...

If it's something I can fix on my end, I'd gladly do so, but I'm just using plain createrepo (and this seems to work with the yum version in question with other distros).

Pass -d to create repo. and it'll work (and be faster).

OK, which version of createrepo should be used (distribution range is EL3-5, F8-10)? Currently I use 0.4.9, but there is even 0.9.6 available.

Any version 0.4.9 or later should be fine (I think even 0.4.4 will work, but I haven't checked). Anything "recent" will also add group_gz which the yum in testing can/will use, but that's just a bonus if it's not a problem to use that.

Or does it not matter wrt the outcome?

In theory the DB is versioned, so you can have createrepo make a version that yum doesn't like ... I don't think this has ever been possible though, and it's very likely we won't use this feature going forward due to the downsides (the client has to download the .sqlite file to work out it can't use it -- and it'd currently "break" mdpolicy).