Panu Matilainen
2006-03-01 18:45:55 UTC
A word of warning: this is probably the biggest change apt-rpm has seen
since the 0.3.x -> 0.5.x codebase switch, it's an incomplete and very
much work-in-progress version and is sure to contain bugs.
If that didn't scary you away: here's a snapshot of my bleeding edge
branch, now with repomd support (you know the repository metadata which
eg Fedora uses...):
http://laiskiainen.org/apt/testing/apt-repomd-01032006.tar.bz2
To go with it there's also a patch to add repomd support to synaptic
(currently svn head only, but can and will rediff against latest
released version if people want) in the directory.
I've been using this for updating my own main box for a couple of weeks
now, hasn't eaten it alive but take care. There are various known
caveats and not-implemented-yet things, at least the following from the
top of my head:
- Package and repository checksums are not verified at all: apt uses
md5sums "natively" whereas repomd uses sha1, needs a bit of abstracting
out. Neither are *that* big a deal in practise - rpm wont install a
malformed package (and you probably want to use GPG checker lua-plugin
anyway), and a broken mirror might cause some interesting effects (I
haven't encountered any yet though)
- Not all file dependencies can be solved. Currently only the data in
primary.xml file is processed, and while that already covers most
typical file dependencies, there are at least a few dependencies in FC4
which would need filelists.xml information. Will get to this eventually.
- Repomd.xml is downloaded but not really used for anything yet (see
above the bit about checksums)
- apt-cache doesn't show full dependency information for packages,
another work-in-progress thingy
- It eats gobs of memory and probably leaks quite a bit of it
- Source repositories of repomd type are not yet supported
- The code is still in middle of heavy reorganization to better support
different repository models without duplicating tons of code
So, it has it's shortcomings but it sure leaves the competition far away
in dust when it comes to speed, even in it's current totally unoptimized
state. :)
Oh and there's a new sources.list entry format for this, as there are no
such things as "sections" in repomd, so it's just
repomd <base url> <distribution>
For example (each entry on a single line of course) for Fedora Core +
Extras:
repomd http://download.fedora.redhat.com/pub/
fedora/linux/core/$(VERSION)/$(ARCH)/os
repomd http://download.fedora.redhat.com/pub/
fedora/linux/extras/$(VERSION)/$(ARCH)/
I'd like some more eyes on this - when testing, watch out for them
little things like incorrect filesizes, odd looking dependencies and
such. The code will still change quite a bit but those little details
are important to get right already. Note that this also means "native"
apt repositories - that code has seen quite a few changes as well in
this process (and yes, mixing old style rpm repos and repomd is supposed
to work without glitches)
- Panu -
since the 0.3.x -> 0.5.x codebase switch, it's an incomplete and very
much work-in-progress version and is sure to contain bugs.
If that didn't scary you away: here's a snapshot of my bleeding edge
branch, now with repomd support (you know the repository metadata which
eg Fedora uses...):
http://laiskiainen.org/apt/testing/apt-repomd-01032006.tar.bz2
To go with it there's also a patch to add repomd support to synaptic
(currently svn head only, but can and will rediff against latest
released version if people want) in the directory.
I've been using this for updating my own main box for a couple of weeks
now, hasn't eaten it alive but take care. There are various known
caveats and not-implemented-yet things, at least the following from the
top of my head:
- Package and repository checksums are not verified at all: apt uses
md5sums "natively" whereas repomd uses sha1, needs a bit of abstracting
out. Neither are *that* big a deal in practise - rpm wont install a
malformed package (and you probably want to use GPG checker lua-plugin
anyway), and a broken mirror might cause some interesting effects (I
haven't encountered any yet though)
- Not all file dependencies can be solved. Currently only the data in
primary.xml file is processed, and while that already covers most
typical file dependencies, there are at least a few dependencies in FC4
which would need filelists.xml information. Will get to this eventually.
- Repomd.xml is downloaded but not really used for anything yet (see
above the bit about checksums)
- apt-cache doesn't show full dependency information for packages,
another work-in-progress thingy
- It eats gobs of memory and probably leaks quite a bit of it
- Source repositories of repomd type are not yet supported
- The code is still in middle of heavy reorganization to better support
different repository models without duplicating tons of code
So, it has it's shortcomings but it sure leaves the competition far away
in dust when it comes to speed, even in it's current totally unoptimized
state. :)
Oh and there's a new sources.list entry format for this, as there are no
such things as "sections" in repomd, so it's just
repomd <base url> <distribution>
For example (each entry on a single line of course) for Fedora Core +
Extras:
repomd http://download.fedora.redhat.com/pub/
fedora/linux/core/$(VERSION)/$(ARCH)/os
repomd http://download.fedora.redhat.com/pub/
fedora/linux/extras/$(VERSION)/$(ARCH)/
I'd like some more eyes on this - when testing, watch out for them
little things like incorrect filesizes, odd looking dependencies and
such. The code will still change quite a bit but those little details
are important to get right already. Note that this also means "native"
apt repositories - that code has seen quite a few changes as well in
this process (and yes, mixing old style rpm repos and repomd is supposed
to work without glitches)
- Panu -