RPM

Bug #645300
Comment #6

Comment 6 for bug 645300

Revision history for this message

In Red Hat Bugzilla #488968, James (james-redhat-bugs) wrote on 2009-03-06:

> This isn't repository meta data nor is it package metadata

How is it not package metadata ... the data comes _directly_ from the packages in the repo.

> Please guys, don't just protest against this because it's not doing things
> the yum way.

This isn't "the yum way" it's "the Fedora way" and "the RHEL way" and "the CentOS way" ... each has a process for getting repo. MD out to clients, and putting it in packages isn't it.
Obviously for Fedora you can just ask FESCO to say that stuff random bits of package data inside a single package is fine ... at which point it doesn't matter if upstream yum developers like it or not, that'll be the new Fedora way.

> Putting icons and all translations in the yum repomd is not suitable
> unless you want to download large amounts of extra metadata every time a few
> packages change

Translations for all .desktop files is less than primar or filelists, icons may be more and so you may want to find a different method than just putting everything in one file and linking it to the repomd.xml.
Install from CD MD will never change, so only new updates in the updates repo. will generate new MD there ... as against the "dump package data in another package" way which will have to update everything, anytime one package hits updates with this data changed. The other option being to intentionally have the package metadata by out of sync. ... and I hope that you aren't planning on that as an option, because that's a huge failure.

> I've got no intention of adding huge amounts of code to yum

Indeed, and I would say that's the biggest problem I have with PK ... not that it's that relevant here, as the infrastructure you _need_ in yum is 0 lines of code ... the sane amount to change would be a little more.
This is all about how you distribute things in Fedora/RHEL/whatever ... so you _need_ to change something around mash time, I think ... but I'm not 100% sure, speak to Jesse etc.

> yum is meant to be a package manager, not an application manager.

I don't see why the distinction applies to yum and not PK. But again this isn't a yum issue, I would have the same objections for the same reasons if we shipped pkcon as the cmd line interface.

> I've been updating hal-info quite a bit in the last few years, and this has
> worked well for this sort of data.

hal-info is not generated directly from package data, so it is not analogous.

> This isn't repository meta data nor is it package metadata

How is it not package metadata ... the data comes _directly_ from the packages in the repo.

> Please guys, don't just protest against this because it's not doing things
> the yum way.

This isn't "the yum way" it's "the Fedora way" and "the RHEL way" and "the CentOS way" ... each has a process for getting repo. MD out to clients, and putting it in packages isn't it.
 Obviously for Fedora you can just ask FESCO to say that stuff random bits of package data inside a single package is fine ... at which point it doesn't matter if upstream yum developers like it or not, that'll be the new Fedora way.

> Putting icons and all translations in the yum repomd is not suitable
> unless you want to download large amounts of extra metadata every time a few
> packages change

Translations for all .desktop files is less than primar or filelists, icons may be more and so you may want to find a different method than just putting everything in one file and linking it to the repomd.xml.
 Install from CD MD will never change, so only new updates in the updates repo. will generate new MD there ... as against the "dump package data in another package" way which will have to update everything, anytime one package hits updates with this data changed. The other option being to intentionally have the package metadata by out of sync. ... and I hope that you aren't planning on that as an option, because that's a huge failure.

> I've got no intention of adding huge amounts of code to yum

Indeed, and I would say that's the biggest problem I have with PK ... not that it's that relevant here, as the infrastructure you _need_ in yum is 0 lines of code ... the sane amount to change would be a little more.
 This is all about how you distribute things in Fedora/RHEL/whatever ... so you _need_ to change something around mash time, I think ... but I'm not 100% sure, speak to Jesse etc.

> yum is meant to be a package manager, not an application manager.

I don't see why the distinction applies to yum and not PK. But again this isn't a yum issue, I would have the same objections for the same reasons if we shipped pkcon as the cmd line interface.

> I've been updating hal-info quite a bit in the last few years, and this has
> worked well for this sort of data.

hal-info is not generated directly from package data, so it is not analogous.