Hi Everyone, I don't want a flamewar, just opinions.
Are there a lot of people who use the two commands listed in the subject very often? I ask b/c there has been some discussion of minimizing the number of copies of the package metadata from the installation.
comps.rpm and rpmdb-fedora take up considerable space and now would be a good time to discuss removing them for FC4.
if yum or some other command line tool were to be able to return the same data from the xml metadata, instead of the comps or rpmdb-fedora, would people be willing to use those?
Thanks -sv
Le jeu 09/09/2004 à 05:40, seth vidal a écrit :
Hi Everyone, I don't want a flamewar, just opinions.
Are there a lot of people who use the two commands listed in the subject very often?
you can add --aid : add suggested packages to transaction --nosuggest : do not suggest missing dependency resolution(s)
I ask b/c there has been some discussion of minimizing the number of copies of the package metadata from the installation.
comps.rpm and rpmdb-fedora take up considerable space and now would be a good time to discuss removing them for FC4.
if yum or some other command line tool were to be able to return the same data from the xml metadata, instead of the comps or rpmdb-fedora, would people be willing to use those?
Thanks -sv
On Thu, 2004-09-09 at 06:36 +0200, Matias Feliciano wrote:
Le jeu 09/09/2004 à 05:40, seth vidal a écrit :
Hi Everyone, I don't want a flamewar, just opinions.
Are there a lot of people who use the two commands listed in the subject very often?
you can add --aid : add suggested packages to transaction --nosuggest : do not suggest missing dependency resolution(s)
And on that subject. Are these often used?
-sv
Le jeu 09/09/2004 à 07:07, seth vidal a écrit :
On Thu, 2004-09-09 at 06:36 +0200, Matias Feliciano wrote:
Le jeu 09/09/2004 à 05:40, seth vidal a écrit :
Hi Everyone, I don't want a flamewar, just opinions.
Are there a lot of people who use the two commands listed in the subject very often?
you can add --aid : add suggested packages to transaction --nosuggest : do not suggest missing dependency resolution(s)
And on that subject. Are these often used?
I think this is not really the point.
I don't often use rpmdb. But sometimes rpmdb is useful in conjunction with "rpm -q -qf" ou "rpm -e --test". Exemple : what packages depend on xorg-x11-deprecated-libs ? # rpm -e --test --dbpath `pwd` xorg-x11-deprecated-libs erreur: Dépendances requises: libXp.so.6 est nécessaire pour (déjà installé) ddd-3.3.9-1 libXp.so.6 est nécessaire pour (déjà installé) nedit-5.4-2 libXp.so.6 est nécessaire pour (déjà installé) openmotif-2.2.3-5 libXp.so.6 est nécessaire pour (déjà installé) openmotif-devel-2.2.3-5 libXp.so.6 est nécessaire pour (déjà installé) openmotif21-2.1.30-11 libXp.so.6 est nécessaire pour (déjà installé) xorg-x11-6.7.99.903-6 libXp.so.6 est nécessaire pour (déjà installé) xorg-x11-tools-6.7.99.903-6 libXp.so.6 est nécessaire pour (déjà installé) xpdf-3.00-5 xorg-x11-deprecated-libs = 6.7.99.903-6 est nécessaire pour (déjà installé) xorg-x11-deprecated-libs-devel-6.7.99.903-6
With a local copy of rawhide, it's easy to create a custom rpmdb with "rpm --initdb" and "rpm -i --justdb --notrigger.... *.rpm"
rpmdb is useful because *rpm* and not because yum !
I am not arguing to keep rpmdb. I am arguing to create something like : - yum install --justdb --dbpath usr/lib/rpmdb/i386-redhat-linux/redhat/ '*' or - repodata2rpmdb http://..../rawhide/repodata http://.../fedora.us/repodata /usr/lib/rpmdb/i386-redhat-linux/redhat/
On Thu, 9 Sep 2004, Matias Feliciano wrote:
Le jeu 09/09/2004 à 07:07, seth vidal a écrit :
On Thu, 2004-09-09 at 06:36 +0200, Matias Feliciano wrote:
Le jeu 09/09/2004 à 05:40, seth vidal a écrit :
Hi Everyone, I don't want a flamewar, just opinions.
Are there a lot of people who use the two commands listed in the subject very often?
you can add --aid : add suggested packages to transaction --nosuggest : do not suggest missing dependency resolution(s)
And on that subject. Are these often used?
I think this is not really the point.
I don't often use rpmdb. But sometimes rpmdb is useful in conjunction with "rpm -q -qf" ou "rpm -e --test". Exemple : what packages depend on xorg-x11-deprecated-libs ? # rpm -e --test --dbpath `pwd` xorg-x11-deprecated-libs erreur: Dépendances requises: libXp.so.6 est nécessaire pour (déjà installé) ddd-3.3.9-1 libXp.so.6 est nécessaire pour (déjà installé) nedit-5.4-2
[...]
This is exactly the kind of madness we (or at least I) would like to *solve* with the new tool. See my other mail about this very thing where 'rpm --whatrequires' fails to give a decent answer.
With a local copy of rawhide, it's easy to create a custom rpmdb with "rpm --initdb" and "rpm -i --justdb --notrigger.... *.rpm"
rpmdb is useful because *rpm* and not because yum !
It (the new tool) doesn't have to depend on yum, just the repomd libraries which currently come from the yum package but could be separated easily, although yum is hardly what I'd call a large package :)
- Panu -
On Thu, 09 Sep 2004 01:07:29 -0400, seth vidal wrote:
On Thu, 2004-09-09 at 06:36 +0200, Matias Feliciano wrote:
Le jeu 09/09/2004 à 05:40, seth vidal a écrit :
Hi Everyone, I don't want a flamewar, just opinions.
Are there a lot of people who use the two commands listed in the subject very often?
you can add --aid : add suggested packages to transaction --nosuggest : do not suggest missing dependency resolution(s)
And on that subject. Are these often used?
FWIW, I use --aid regularly for installs from a FC mirror on local disk. And I use rpmdb-fedora based queries for checking conflicts and directory ownerships of fedora.us packages.
On Thu, Sep 09, 2004 at 01:07:29AM -0400, seth vidal wrote:
On Thu, 2004-09-09 at 06:36 +0200, Matias Feliciano wrote:
Le jeu 09/09/2004 à 05:40, seth vidal a écrit :
Hi Everyone, I don't want a flamewar, just opinions.
Are there a lot of people who use the two commands listed in the subject very often?
you can add --aid : add suggested packages to transaction --nosuggest : do not suggest missing dependency resolution(s)
And on that subject. Are these often used?
I use --aid all the time, and would *really* miss the rpmdb data it requires.
Tim. */
On Thu, 2004-09-09 at 05:40, seth vidal wrote:
Hi Everyone, I don't want a flamewar, just opinions.
OK, here is mine:
Are there a lot of people who use the two commands listed in the subject very often? I ask b/c there has been some discussion of minimizing the number of copies of the package metadata from the installation.
comps.rpm and rpmdb-fedora take up considerable space and now would be a good time to discuss removing them for FC4.
Good idea.
if yum or some other command line tool were to be able to return the same data from the xml metadata, instead of the comps or rpmdb-fedora, would people be willing to use those?
IMO, the only tool that is relevant here is "rpm", not "some other command line tool" and definitely not "yum", because the package management system being used is "rpm", not yum, apt nor up2date.
I.e. if you want to make metadata the exclusive and normative source of available packages, the next step would be to enable rpm to process them. Alternatively, I could imagine "some other command tool" could replace "rpm --redhat-*" as part of the rpm package.
Ralf
if yum or some other command line tool were to be able to return the same data from the xml metadata, instead of the comps or rpmdb-fedora, would people be willing to use those?
IMO, the only tool that is relevant here is "rpm", not "some other command line tool" and definitely not "yum", because the package management system being used is "rpm", not yum, apt nor up2date.
well, in this particular case there is no pkg mgmt going on.
it's just querying an rpmdb that is not frequently updated, tbh.
I.e. if you want to make metadata the exclusive and normative source of available packages, the next step would be to enable rpm to process them. Alternatively, I could imagine "some other command tool" could replace "rpm --redhat-*" as part of the rpm package.
so to make sure I'm hearing you right:
either: make rpm parse the xml repodata directly
or:
provide another 'some other command tool' that replaces the popt macro for 'rpm --redhat-*'?
-sv
On Thu, 2004-09-09 at 06:59, seth vidal wrote:
if yum or some other command line tool were to be able to return the same data from the xml metadata, instead of the comps or rpmdb-fedora, would people be willing to use those?
IMO, the only tool that is relevant here is "rpm", not "some other command line tool" and definitely not "yum", because the package management system being used is "rpm", not yum, apt nor up2date.
I.e. if you want to make metadata the exclusive and normative source of available packages, the next step would be to enable rpm to process them. Alternatively, I could imagine "some other command tool" could replace "rpm --redhat-*" as part of the rpm package.
so to make sure I'm hearing you right:
either: make rpm parse the xml repodata directly
or:
provide another 'some other command tool' that replaces the popt macro for 'rpm --redhat-*'?
Yes, this is essentially what I had in mind.
In particular I was thinking along the lines of shipping a metadata*rpm, to replace rpmdb-fedora*rpm, because I'd expect the info contained in both of them to be completely equivalent.
Yum then could use this rpmdb-fedora-replacement rpm to setup its initial package-metadata/header cache etc.
Another aspect, I am not sure about is if and how to reflect dynamically set up metadata-caches to "rpm --redhat-*". On one hand, ATM, rpm doesn't know anything about yum/apt/up2date, so not considering this case would not be a regression. On the other hand, if rpm is able to read metadata-files/caches, it should not be too be difficult to extended it to read arbitrary metadata-files/caches such as the ones being used by yum.
Ralf
In particular I was thinking along the lines of shipping a metadata*rpm, to replace rpmdb-fedora*rpm, because I'd expect the info contained in both of them to be completely equivalent.
Yum then could use this rpmdb-fedora-replacement rpm to setup its initial package-metadata/header cache etc.
well, yum doesn't need an initial header cache anymore - as of 2.1.X - it only needs the headers of the packages it will actually use in the transaction.
Another aspect, I am not sure about is if and how to reflect dynamically set up metadata-caches to "rpm --redhat-*". On one hand, ATM, rpm doesn't know anything about yum/apt/up2date, so not considering this case would not be a regression. On the other hand, if rpm is able to read metadata-files/caches, it should not be too be difficult to extended it to read arbitrary metadata-files/caches such as the ones being used by yum.
Would it be presumptive to start thinking about tying more things around remote repositories or at least a set of repositories rather than a local cache of information?
-sv
On Thu, 09 Sep 2004 07:34:27 +0200, Ralf Corsepius wrote:
provide another 'some other command tool' that replaces the popt macro for 'rpm --redhat-*'?
Yes, this is essentially what I had in mind.
+1
rpmdb-fedora is very useful, but is not updated after all the Fedora Core updates unless you do that yourself with --justdb and related RPM options.
On Thu, 9 Sep 2004, Michael Schwendt wrote:
On Thu, 09 Sep 2004 07:34:27 +0200, Ralf Corsepius wrote:
provide another 'some other command tool' that replaces the popt macro for 'rpm --redhat-*'?
Yes, this is essentially what I had in mind.
+1
rpmdb-fedora is very useful, but is not updated after all the Fedora Core updates unless you do that yourself with --justdb and related RPM options.
I'm starting to have funny ideas about 'repoquery' (or whatever you want to call it) which does what rpmquery does but handles seamlessly both rpmdb and repository metadata information. AND provides meaningful answers to things like '--whatrequires foo' - this is one of my "favorites":
[pmatilai@chip pmatilai]$ rpm -q --whatrequires openssl libpcap-0.8.3-3 curl-7.11.1-1 openssl-devel-0.9.7a-35 w3m-0.5-3 sendmail-8.12.11-4.6 dovecot-0.99.10.6-1,FC2,1 kdelibs-3.2.2-8.FC2 [pmatilai@chip pmatilai]$
A whopping 5 packages. Yet what REALLY requires openssl:
[pmatilai@chip pmatilai]$ rpm -q --whatrequires `rpm -q --provides openssl`|grep -v "no package"|sort -u|wc -l 55 [pmatilai@chip pmatilai]$
Ooops...
- Panu -
On Thu, 9 Sep 2004 12:58:17 +0300 (EEST), Panu Matilainen wrote:
I'm starting to have funny ideas about 'repoquery' (or whatever you want to call it) which does what rpmquery does but handles seamlessly both rpmdb and repository metadata information. AND provides meaningful answers to things like '--whatrequires foo' - this is one of my "favorites":
[pmatilai@chip pmatilai]$ rpm -q --whatrequires openssl libpcap-0.8.3-3 curl-7.11.1-1 openssl-devel-0.9.7a-35 w3m-0.5-3 sendmail-8.12.11-4.6 dovecot-0.99.10.6-1,FC2,1 kdelibs-3.2.2-8.FC2 [pmatilai@chip pmatilai]$
A whopping 5 packages. Yet what REALLY requires openssl:
[pmatilai@chip pmatilai]$ rpm -q --whatrequires `rpm -q --provides openssl`|grep -v "no package"|sort -u|wc -l 55 [pmatilai@chip pmatilai]$
Ooops...
Yes, that's due to automatically generated dependencies on the openssl library sonames (libssl.so.4 and libcrypto.so.4)
$ rpm -q --whatrequires $(rpm -q --provides openssl | grep lib) | wc -l 77
An interesting part about creating a new repoquery/rpmquery would be to create high-level queries which "know" how to find out which packages depend on "openssl" rather than letting the user find out complex queries like above.
On Thu, 9 Sep 2004, Michael Schwendt wrote:
On Thu, 9 Sep 2004 12:58:17 +0300 (EEST), Panu Matilainen wrote:
I'm starting to have funny ideas about 'repoquery' (or whatever you want to call it) which does what rpmquery does but handles seamlessly both rpmdb and repository metadata information. AND provides meaningful answers to things like '--whatrequires foo' - this is one of my "favorites":
[pmatilai@chip pmatilai]$ rpm -q --whatrequires openssl libpcap-0.8.3-3 curl-7.11.1-1 openssl-devel-0.9.7a-35 w3m-0.5-3 sendmail-8.12.11-4.6 dovecot-0.99.10.6-1,FC2,1 kdelibs-3.2.2-8.FC2 [pmatilai@chip pmatilai]$
A whopping 5 packages. Yet what REALLY requires openssl:
[pmatilai@chip pmatilai]$ rpm -q --whatrequires `rpm -q --provides openssl`|grep -v "no package"|sort -u|wc -l 55 [pmatilai@chip pmatilai]$
Ooops...
Yes, that's due to automatically generated dependencies on the openssl library sonames (libssl.so.4 and libcrypto.so.4)
$ rpm -q --whatrequires $(rpm -q --provides openssl | grep lib) | wc -l 77
An interesting part about creating a new repoquery/rpmquery would be to create high-level queries which "know" how to find out which packages depend on "openssl" rather than letting the user find out complex queries like above.
Well that's what I said above: "...provides meaningful answers to things like '--whatrequires foo'". Will work on this and based on a quick look inside repomd/*.py actually like it as well :)
And along this road I'm perfectly willing to dump 1:1 rpmquery compatibility for something that's both user- and script-friendly.
- Panu -
Hello, On Wed, Sep 08, 2004 at 11:40:27PM -0400, seth vidal wrote:
Are there a lot of people who use the two commands listed in the subject very often?
I use something more general:
$ cat .popt rpm alias --fedora --nogpg --dbpath /usr/lib/rpmdb/%{_arch}-%{_vendor}-%{_os}/redhat $
Then (rpm --fedora -q --whatprovides PACKAGE), (rpm --fedora -qf FILE), (rpm --fedora -ql PACKAGE), (rpm --fedora -ev --test PACKAGE) etc., I tend to use this very often (daily is a good estimate).
if yum or some other command line tool were to be able to return the same data from the xml metadata, instead of the comps or rpmdb-fedora, would people be willing to use those?
I don't think the XML metadata allows so general queries and I'm not sure what is the subset of rpmdb data that would be enough to completely replace all the ways I have ever used rpmdb.
But if the rpmdb is not available in the distribution, I can always create my own, so ths mail does not imply "I don't want rpmdb removed". Mirek
Then (rpm --fedora -q --whatprovides PACKAGE), (rpm --fedora -qf FILE), (rpm --fedora -ql PACKAGE), (rpm --fedora -ev --test PACKAGE) etc., I tend to use this very often (daily is a good estimate).
I dare say your use is extremely special.
I don't think the XML metadata allows so general queries and I'm not sure what is the subset of rpmdb data that would be enough to completely replace all the ways I have ever used rpmdb.
umm. The xml metadata allows whatever query the tool that is accessing it allows. the intent of yum is to be somewhat simpler for a given subset of commands but the xml metadata provides a significant fraction of the data that is normally in an rpmdb. Not the file checksums, to be sure, but it does provide:
changelogs files dirs provides/obsoletes/conflicts/requires standard info on a package (rpm -qpi type stuff)
it might be worthwhile to implement a general query tool for the xml metadata. Anyone interested?
-sv
On Wed, 8 Sep 2004, seth vidal wrote:
Hi Everyone, I don't want a flamewar, just opinions.
Are there a lot of people who use the two commands listed in the subject very often? I ask b/c there has been some discussion of minimizing the number of copies of the package metadata from the installation.
Often? No. Occasionally yes, although that tends to be on either a) ancient b) standalone boxes. Because of the static nature of rpmdb-redhat it grows more useless over time especially on distro like FC where packages get renamed during the release lifetime and updates are fast and furious. What I would miss probably is the formatting capabilities of rpm --qf which makes it useful from scripts for certain things.
comps.rpm and rpmdb-fedora take up considerable space and now would be a good time to discuss removing them for FC4.
comps.rpm has the same problem of being a static entity and a rather strange beast at that. I wouldn't miss it a single day as long as the equivalent of comps.xml is somewhere around.. but the information is more important for systems without network connectivity (or if you just happen to *love* shuffling CD's back and forth to install stuff)
if yum or some other command line tool were to be able to return the same data from the xml metadata, instead of the comps or rpmdb-fedora, would people be willing to use those?
Oh absolutely, if the command line tool can grok rpm's --queryformat syntax or equivalent alternative (but compatibility with rpm would be quite important I think so rpm --qf junkies like me don't have to relearn a new query "language" :)
- Panu -
Often? No. Occasionally yes, although that tends to be on either a) ancient b) standalone boxes. Because of the static nature of rpmdb-redhat it grows more useless over time especially on distro like FC where packages get renamed during the release lifetime and updates are fast and furious. What I would miss probably is the formatting capabilities of rpm --qf which makes it useful from scripts for certain things.
I think all that functionality is housed in popt, but yah - I agree it is handy.
comps.rpm has the same problem of being a static entity and a rather strange beast at that. I wouldn't miss it a single day as long as the equivalent of comps.xml is somewhere around.. but the information is more important for systems without network connectivity (or if you just happen to *love* shuffling CD's back and forth to install stuff)
What are these "systems without network connectivity" that you speak of? :) Actually, there was also some discussion this evening of if the xml-metadata could store cd information in an additional attribute in the <location> tag. Specifically for things like system-config-packages and anaconda to be able to use the metadata with removable media.
Oh absolutely, if the command line tool can grok rpm's --queryformat syntax or equivalent alternative (but compatibility with rpm would be quite important I think so rpm --qf junkies like me don't have to relearn a new query "language" :)
you know... if you're interested, it would be a fun time to learn the repomd module for accessing the metadata. :)
-sv
On Thu, 9 Sep 2004, seth vidal wrote:
Often? No. Occasionally yes, although that tends to be on either a) ancient b) standalone boxes. Because of the static nature of rpmdb-redhat it grows more useless over time especially on distro like FC where packages get renamed during the release lifetime and updates are fast and furious. What I would miss probably is the formatting capabilities of rpm --qf which makes it useful from scripts for certain things.
I think all that functionality is housed in popt, but yah - I agree it is handy.
Yup it's heavily tied into popt but I'm not too familiar with the details .. hmm, popt-python anybody? :) Anyway need to have a closer look at how the thing works.
comps.rpm has the same problem of being a static entity and a rather strange beast at that. I wouldn't miss it a single day as long as the equivalent of comps.xml is somewhere around.. but the information is more important for systems without network connectivity (or if you just happen to *love* shuffling CD's back and forth to install stuff)
What are these "systems without network connectivity" that you speak of? :)
Creatures from our worst nightmares? :)
Actually, there was also some discussion this evening of if the xml-metadata could store cd information in an additional attribute in the <location> tag. Specifically for things like system-config-packages and anaconda to be able to use the metadata with removable media.
Indeed. People with modem-only internet access <shrudder> still exist and for those it's important that the new metadata works with removable media. And anaconda as well of course.
Oh absolutely, if the command line tool can grok rpm's --queryformat syntax or equivalent alternative (but compatibility with rpm would be quite important I think so rpm --qf junkies like me don't have to relearn a new query "language" :)
you know... if you're interested, it would be a fun time to learn the repomd module for accessing the metadata. :)
Sure, why not, should be a fun project. I should start having a bit more time to use for freetime hacking in a few weeks. If you start something let me know.
- Panu -
Actually, there was also some discussion this evening of if the xml-metadata could store cd information in an additional attribute in the <location> tag. Specifically for things like system-config-packages and anaconda to be able to use the metadata with removable media.
Indeed. People with modem-only internet access <shrudder> still exist and for those it's important that the new metadata works with removable media. And anaconda as well of course.
Check my post to rpm-metadata list and comment. If it seems reasonable then it's a way to go.
it'll take some work to put that in createrepo, though.
Sure, why not, should be a fun project. I should start having a bit more time to use for freetime hacking in a few weeks. If you start something let me know.
if you install yum 2.1.3 from rawhide you'll have a good version of the repomd module.
Some new updates added in cvs but the concepts are more or less there.
Also paul nasrat has been working on something related.
Drop by #fedora-devel on irc and ping at me or nasrat about it. I'd love to get a quick and simple tool to parse the files and dump the outputs.
-sv
-
Féliciano Matias -
Michael Schwendt -
Miloslav Trmač -
Panu Matilainen -
Ralf Corsepius -
seth vidal -
Tim Waugh