Ticket #38 (closed enhancement: wontfix)

Opened 7 years ago

Last modified 6 years ago

add support for deltarpms

Reported by: katzj Owned by: mikem
Priority: major Milestone:
Component: hub Version: 1.2.2
Keywords: Cc: pirast, jdieter
Blocked By: Blocking:

Description

We want to have the ability to create and store deltarpms within koji. Basic idea is to be able to request specific deltas and also to have them created.

This can then be used by mash, bodhi, etc to generate repos that are compatible with the yum-presto plugin so that users can download less data for updates.

Attachments

make_delta_from_sig.py (4.3 KB) - added by jdieter 6 years ago.
A small library/program that allows you to attach a signature to a deltarpm

Change History

comment:1 Changed 7 years ago by pirast

  • Cc pirast added

comment:2 Changed 6 years ago by jdieter

  • Cc jdieter added

What's the status on this? What needs to happen for this to be implemented?

comment:3 Changed 6 years ago by mikem

  • Owner changed from mikeb to mikem

The problem is that this feature does not mesh well with Koji. It's easy to say "Koji should do this," but at present it seems that any implementation would be an ugly, complicated hack. The problem is rpm signatures.

RPMs can be signed multiple times. Koji keeps a 'canonical' copy of the rpms for a build, but can also track multiple signatures. It does this by storing signature headers in a separate directory. Koji has code to rip and splice these signature headers, so it can create differently signed copies as needed.

So the thing is, when you ask for an rpmdelta between two rpms, you almost certainly don't care about the canonical rpms Koji uses for storage, you want the specifically signed copies. This is where it gets messy.

At first we hoped it might be possible to tear apart the delta and swap out the signature header as we do with the full rpm. It turns out that this is much more complicated and IO-intensive than we expected. It appears that the signature header of the delta rpm is not the same as the one for $newrpm. The deltarpm has an md5-only signature header matching its payload. The original signature rpm must live in the payload somewhere, but it is not there literally (at least, I haven't found any additional header magic sequences in my experiments).

So it seems that in order to change the signature of a deltarpm, we would need to tear apart the payload, put it back together again, and recalculate the md5 for the real signature header (and I'm still not 100% sure this can be done without effectively applying the delta, splicing the signature, and re-deltaing). In any case, this is significantly more complicated than splicing a signature into a normal rpm.

I realize the importance of getting the deltarpms into our repos, but I would like to suggest again that this problem be solved /outside/ of koji.

Changed 6 years ago by jdieter

A small library/program that allows you to attach a signature to a deltarpm

comment:4 Changed 6 years ago by jdieter

I've attached a small python library (that can be run as a stand-alone program) that will attach a signature to a deltarpm *without* using needing loads of IO. You do need deltarpm-3.4-9 (available at http://koji.fedoraproject.org/packages/deltarpm/3.4/9.fc9/i386/deltarpm-3.4-9.fc9.i386.rpm and soon in devel) to be able to use deltarpms modified using this code. (Older versions of deltarpm will create the correct rpm, but will complain that the md5 checksum has changed. Running rpm -V will verify that the rpm is, indeed, correct.)

I'm afraid I don't know whether or not koji is the correct place for this, but this code should help where-ever we end up putting it.

comment:5 Changed 6 years ago by mikem

jdieter: So there is a format change/extension in play? It seems to me we need to support the version of deltarpm that yum+presto users will have on their system.

comment:6 Changed 6 years ago by jdieter

Yes, there's a format extension here. As you've seen, deltarpm has an md5 checksum for the whole rpm. It's generating this after attaching a signature that's quite difficult. So we just go and set that md5 sum to "\x00" * 16. Old versions of deltarpm will generate the rpm, but complain about an md5 checksum mismatch. New versions of deltarpm will see the zero'd out md5 checksum and use the rpm's md5 checksum (which ignores the signature and is therefore the same, no matter what signature is attached).

deltarpm-3.4-9 has just gone into Rawhide and I'm planning on pushing it into at least Fedora 8. Any users of yum-presto with the old rpm will get an error message saying "Error rebuilding rpm. Will download full package", but it won't crash yum for them (they'll just download the full rpms as if yum-presto isn't there).

comment:7 follow-up: ↓ 8 Changed 6 years ago by jdieter

I've set up a koji server locally, along with a minimal distribution and now understand more of how koji works. A couple of thoughts on earlier comments and implementation options:

When it comes to what to generate deltarpms for, we have two choices:

  • Generate deltarpms only for F9+ (the deltarpm in Rawhide understands deltarpms without an md5 of the whole signed rpm).
  • Store the md5 checksums of the signed rpms, and then attach it to the deltarpms when attaching the signature. This will require bigger changes in how the signing process works, but will allow us to generate deltarpms for F7 and F8.

I would probably go with the first option of the two above as it doesn't seem to be worth the extra work just to support deltarpms in F7 and F8.

When it comes to generating deltarpms, we have a couple of choices:

  • Store deltarpm information in koji. Add a xmlrpc call to generate deltarpms for specified rpms that could be called by bodhi. Koji-builder would actually generate the deltarpms. Add signatures to deltarpms at same time as they are added to rpms.
  • Do everything that has to do with deltarpms completely separate from koji. Write a completely separate program that will maintain the deltarpms and add signatures to them. This program would interact with bodhi directly.

I would tend to go with the first option here as well as it seems a bit crazy to have something else controlling the deltarpms when koji does seem well-suited to it (especially if the signature problem is dealt with).

The reason I'm listing the problems here is that I'm willing to do the work either in koji or writing something new, but I need to know if you strongly feel that koji *isn't* the place for deltarpms.

comment:8 in reply to: ↑ 7 ; follow-up: ↓ 9 Changed 6 years ago by mikem

Replying to jdieter:

  • Generate deltarpms only for F9+ (the deltarpm in Rawhide understands deltarpms without an md5 of the whole signed rpm).

Won't this cause problems for folks using 'yum upgrade' from an earlier release?

  • Store the md5 checksums of the signed rpms, and then attach it to the deltarpms when attaching the signature. This will require bigger changes in how the signing process works, but will allow us to generate deltarpms for F7 and F8.

Storing is pretty easy, but generating them in the first place is expensive.

I would probably go with the first option of the two above as it doesn't seem to be worth the extra work just to support deltarpms in F7 and F8.

again, I'm worried about yum upgrades from these releases.

When it comes to generating deltarpms, we have a couple of choices:

  • Store deltarpm information in koji. Add a xmlrpc call to generate deltarpms for specified rpms that could be called by bodhi. Koji-builder would actually generate the deltarpms. Add signatures to deltarpms at same time as they are added to rpms.

Do you mean you want to farm the deltarpm generation out to the build hosts? This would mean making it a task, which makes the process asynchronous (which will make things a little more complicated for the client). Also note the build hosts do not have write access to file share, which means they'd have to upload the results. It might be interesting to try this, but I'm not sure it's the right thing.

  • Do everything that has to do with deltarpms completely separate from koji. Write a completely separate program that will maintain the deltarpms and add signatures to them. This program would interact with bodhi directly.

I would tend to go with the first option here as well as it seems a bit crazy to have something else controlling the deltarpms when koji does seem well-suited to it (especially if the signature problem is dealt with).

I still think it is reasonable to keep deltarpms out of koji. The intended use is for repo generation, which involves storing lots of data outside of koji. I consider it roughly analogous to createrepo's cachedir feature.

After all, don't non-koji-users deserve a reasonable tool for handling this sort of situation?

The reason I'm listing the problems here is that I'm willing to do the work either in koji or writing something new, but I need to know if you strongly feel that koji *isn't* the place for deltarpms.

I would prefer if it were handled elsewhere, but I am willing to consider patches for this in Koji as long as they are not too invasive.

comment:9 in reply to: ↑ 8 Changed 6 years ago by jdieter

Replying to mikem:

Replying to jdieter:

  • Generate deltarpms only for F9+ (the deltarpm in Rawhide understands deltarpms without an md5 of the whole signed rpm).

Won't this cause problems for folks using 'yum upgrade' from an earlier release?

If we don't generate F8->F9 deltarpms, it will never be a problem. And we weren't planning on generating those deltarpms. Our real problem is that the deltarpms really need to be generated *before* signing, otherwise it will delay pushing updates by a couple of hours, minimum (at least, that's what it takes on my test server). I think this is the best of a couple of non-optimal solutions.

<snip>

  • Do everything that has to do with deltarpms completely separate from koji. Write a completely separate program that will maintain the deltarpms and add signatures to them. This program would interact with bodhi directly.

I would tend to go with the first option here as well as it seems a bit crazy to have something else controlling the deltarpms when koji does seem well-suited to it (especially if the signature problem is dealt with).

I still think it is reasonable to keep deltarpms out of koji. The intended use is for repo generation, which involves storing lots of data outside of koji. I consider it roughly analogous to createrepo's cachedir feature.

After all, don't non-koji-users deserve a reasonable tool for handling this sort of situation?

Okay, this is very reasonable, so I think we'll go ahead and write something new to do all the deltarpm work. The last reason is especially persuasive. I'd love to see projects using plague that are able to use whatever we come up with.

If you want to close this ticket (too bad there's no "DONE_ELSEWHERE" resolution), go ahead. For others watching this bug, you may want to watch https://fedorahosted.org/bodhi/ticket/160 for bodhi integration.

comment:10 Changed 6 years ago by mikem

  • Status changed from new to closed
  • Resolution set to wontfix

Closing wontfix -- see previous comment.

Note: See TracTickets for help on using tickets.