[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Better pdiff handling for apt

On Sat, Jan 04, 2014 at 07:34:07PM +0100, David Kalnischkies wrote:
> So, I guess merging both could cross a lot of points of your list and
> be relatively easily feed into unstable for proper field-testing.
> (a upload of my part was planed as a christmas present to experimental,
>  but as usual: If you want to make deity laugh, tell her your plans)

I just did this merging the other day and Michael pushed it to experimental
(again), so everyone should feel free to give it a spin, you might be in
for a pleasant surprise – depending on how much you trusted the
"benchmark" in my previous mail.

[technical, it was indeed as easy as using my POC and Anthonys rred and
 put some minor glue between them – very nice :D ]

Breakage potential:
I decided for now to enable client-side merge by default but with
detection for the X-Patch-Precedence field reprepro has introduced¹ if it
has merged patches on the server side, which falls back to the old
handling. There is no fallback from client-side to server-side in case
the previous one fails: It is just assumed that pdiffs are bad in this
case and we proceed with the download of the complete indexes.
(could be done if really needed, but I doubt it is because:)

I have no knowledge about other implementations of server-merge and
somehow I doubt there are any, but if there are and they have similar
fields I am happy to detect it as well – otherwise they should just
add this field and be done. The alternative of using a new field for
client-merge kinda sucks and big changes to the diffIndex format will
probably take a little while longer to discussed/implemented/adopted.
(It's not that I personally like the field name, but it is used in the
 wild and documented(!), so why not.)

Many questions remain, but I guess we are better off carrying this over
to debian-dak@l.d.o² as d-d@ is usually not so talkative if native tools
are the topic (q.e.d.).
Are you maybe willing to drive this, Anthony?
I have the feeling that there is a lot to be talked about in the area of
pdiffs but nobody so far had the energy to get it really started.

Best regards

David Kalnischkies

¹ as documented in https://wiki.debian.org/RepositoryFormat
² "we" "agreed" some time ago that this is the right list for changes
  to the repository format effecting possibly all clients/servers.

Attachment: signature.asc
Description: Digital signature

Reply to: