rpm-md metadata for online updates
I think this has been shortly addressed several weeks (or even months)
ago, and I can remember AJ (or was it Adrian?) who said to have a look
at it..
Wouldn't it be possible to create rpm-md metadata for the Online
Update packages ?
Would make it very convenient to use from y2pmsh or smart.
And IMO it shouldn't be that much work (createrepo .)
thanks
--
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On Mon, 6 Mar 2006, Pascal Bleser wrote:
I think this has been shortly addressed several weeks (or even months) ago, and I can remember AJ (or was it Adrian?) who said to have a look at it..
Wouldn't it be possible to create rpm-md metadata for the Online Update packages ?
Would make it very convenient to use from y2pmsh or smart.
Indeed.
And IMO it shouldn't be that much work (createrepo .)
#128607 -- it looks quite easy at the first glance, but turns out to be a bit more tricky on our side ;) Regards Christoph
Christoph Thiel wrote:
#128607 -- it looks quite easy at the first glance, but turns out to be a bit more tricky on our side ;)
Care to elaborate on that? Then only thing I could think about "tricky" is how to handle the scripts (nvidia, fonts, and such), which could be easily handled by packaging them on rpm files and running the scripts on %post. (just an opinion, not bashing). -- % Mauricio Teixeira (netmask) % mteixeira{a}webset{d}net <> Maceio/AL/BR % http://mteixeira.webset.net <> http://pmping.sf.net
On Mon, 6 Mar 2006, Mauricio Teixeira wrote:
Christoph Thiel wrote:
#128607 -- it looks quite easy at the first glance, but turns out to be a bit more tricky on our side ;)
Care to elaborate on that?
Rudi, I guess it's your turn ;)
Then only thing I could think about "tricky" is how to handle the scripts (nvidia, fonts, and such), which could be easily handled by packaging them on rpm files and running the scripts on %post. (just an opinion, not bashing).
Regards Christoph
On Mon, 6 Mar 2006, Christoph Thiel wrote:
On Mon, 6 Mar 2006, Mauricio Teixeira wrote:
Christoph Thiel wrote:
#128607 -- it looks quite easy at the first glance, but turns out to be a bit more tricky on our side ;)
Care to elaborate on that?
Rudi, I guess it's your turn ;)
well, in short: it will take some hours of coding something similar to createrepo, but with a far more elaborate caching. createrepo is far too slow, roughly 6 minutes for the 10.0 update tree alone on a fast machine and still almost 3 minutes with checksum caching is far above anything usable. After all, if a new patch is added, this is just about adding a handfull of new rpms and that must never take that long. Some other things are pretty annoying with it, mainly not being able to exclude symlinks and probably more. I hope to get something done within one or two weeks.
Then only thing I could think about "tricky" is how to handle the scripts (nvidia, fonts, and such), which could be easily handled by packaging them on rpm files and running the scripts on %post. (just an opinion, not bashing).
These "special hacks" like scripts and so on would not be found in a normal yum repository, but I don't think this is a major issue to get the thing started. -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux fatou 2.6.16-rc3-git3-2-smp #1 SMP Wed Feb 15 15:03:23 UTC 2006 x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417
On Tue, 7 Mar 2006, Ruediger Oertel wrote:
#128607 -- it looks quite easy at the first glance, but turns out to be a bit more tricky on our side ;)
Care to elaborate on that?
Rudi, I guess it's your turn ;)
well, in short: it will take some hours of coding something similar to createrepo, but with a far more elaborate caching. createrepo is far too slow, roughly 6 minutes for the 10.0 update tree alone on a fast machine and still almost 3 minutes with checksum caching is far above anything usable.
After all, if a new patch is added, this is just about adding a handfull of new rpms and that must never take that long. Some other things are pretty annoying with it, mainly not being able to exclude symlinks and probably more.
I hope to get something done within one or two weeks.
+ this is something for SUSE <= 10.0 only, as 10.1 will feature some new rpm-md-alike update trees ;) Regards Christoph
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph Thiel wrote:
On Tue, 7 Mar 2006, Ruediger Oertel wrote: ...
I hope to get something done within one or two weeks.
+ this is something for SUSE <= 10.0 only, as 10.1 will feature some new rpm-md-alike update trees ;)
Yes but please take care of SUSE <= 10.0 as well.
Not everyone is using factory, and it will take time until everyone is using 10.1.
Thanks for taking care of that bugzilla item.
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ruediger Oertel wrote:
On Mon, 6 Mar 2006, Christoph Thiel wrote:
On Mon, 6 Mar 2006, Mauricio Teixeira wrote:
Christoph Thiel wrote:
#128607 -- it looks quite easy at the first glance, but turns out to be a bit more tricky on our side ;) Care to elaborate on that? Rudi, I guess it's your turn ;)
well, in short: it will take some hours of coding something similar to createrepo, but with a far more elaborate caching. createrepo is far too slow, roughly 6 minutes for the 10.0 update tree alone on a fast machine and still almost 3 minutes with checksum caching is far above anything usable.
After all, if a new patch is added, this is just about adding a handfull of new rpms and that must never take that long. Some other things are pretty annoying with it, mainly not being able to exclude symlinks and probably more.
I hope to get something done within one or two weeks.
Thanks again for taking care of this :)
How about filing those modifications to upstream ?
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On Tue, 7 Mar 2006, Pascal Bleser wrote:
well, in short: it will take some hours of coding something similar to createrepo, but with a far more elaborate caching. createrepo is far too slow, roughly 6 minutes for the 10.0 update tree alone on a fast machine and still almost 3 minutes with checksum caching is far above anything usable.
After all, if a new patch is added, this is just about adding a handfull of new rpms and that must never take that long. Some other things are pretty annoying with it, mainly not being able to exclude symlinks and probably more.
I hope to get something done within one or two weeks.
Thanks again for taking care of this :)
How about filing those modifications to upstream ?
Might be a bit problematic, as our whole patch management stuff is perl-based and the upstream createrepo is python-based ;) But I guess we could at least suggest this upstream, once we have the bits and pieces in place. Regards Christoph
Op maandag 6 maart 2006 17:26, schreef Pascal Bleser:
Would make it very convenient to use from y2pmsh or smart.
And even apt :) The latest version has been extended with repomd support, indeed. Development on this functionality is still going on, but an initial version has been released. The rpms are available from my apt component (suser-rbos), apt version is 0.5.15repomd060302 -- Richard Bos Without a home the journey is endless
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Bos wrote:
Op maandag 6 maart 2006 17:26, schreef Pascal Bleser:
Would make it very convenient to use from y2pmsh or smart.
And even apt :) The latest version has been extended with repomd support, indeed. Development on this functionality is still going on, but an initial version has been released. The rpms are available from my apt component (suser-rbos), apt version is 0.5.15repomd060302
Does that mean apt-rpm has a maintainer?
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
Op maandag 6 maart 2006 21:22, schreef Pascal Bleser:
And even apt :) The latest version has been extended with repomd support, indeed. Development on this functionality is still going on, but an initial version has been released. The rpms are available from my apt component (suser-rbos), apt version is 0.5.15repomd060302
Does that mean apt-rpm has a maintainer?
No, not as such. The guy that added this functionality already helped a lot during Gustavo Niemeyer apt maintenance time. He now decided to add this functionality to apt. He'll continue to improve this code, but I don't know how much responsibility he wants to take. For now just let it grow ;) -- Richard Bos Without a home the journey is endless
* Pascal Bleser (pascal.bleser@skynet.be) [20060306 21:22]:
Does that mean apt-rpm has a maintainer?
Yes and no :) This is from a mail exchange I had with the guy:
Well, from a maintenance point it's IMO pratically dead as Gustavo is now working on smart.
Yup, it's been dead for all practical purposes until I just recently picked it up again. Repomd support is well underway and it now also doesn't totally blow up on multilib systems, support for rpm runtime probe dependencies has been added and I have a *long* list of other things to do as well (if I find the time and enough people are interested in the zombie still ;)
So *if* enough people interested in maintaining apt will show up, apt my have an interesting life after all. Philipp
participants (6)
-
Christoph Thiel -
Mauricio Teixeira -
Pascal Bleser -
Philipp Thomas -
Richard Bos -
Ruediger Oertel