dpkg-source and gitish patches
Guillem Jover writes ("Re: Bug#759999: dpkg-dev: please make mtimes of packaged files deterministic"):
> The --clamp-mtime options looks primising, but I'm not happy about its
> current situation. Please get this upstreamed first. I don't mind making
> dpkg depend on an extremely recent GNU tar, but I really don't want to
> use a Debian specific option like this, as it could change semantics,
> etc. And I don't like parsing --help output at all. I still have to fix
> the situation with dpkg-source using the Debian specifi gzip --rsyncable
> option, for example. :(
This reminds me of something I was meaning to ask you about. Sorry to
derail the conversation, but:
I discovered recently that wheezy cannot unpack some source packages
that are in jessie-backports, because they contain (in their 3.0
(quilt) stack) gitish patches that earlier versions of patch do not
properly understand.
(ISTM also possible that under other circumstances such patches might
be partially applied (eg, only file content changes and not mode
changes, or not renames, or something). IDK whether this is actually
a risk.)
Was this non-backwards-compatible change to the source format
introduced deliberately ?
AFAICT there is no way in dpkg-source to control this compatibility
aspect: ie, there is no way to say `please generate only traditional
format "3.0 (quilt)" packages'; nor to say `this source will not be
transferred properly unless a gitish patch is used, so the new
features must be available'.
Do you think there should be such a mechanism ? What should it look
like ?
ISTM that the next time we make a change like this it ought to be done
by the maintainer explicitly requesting a new source format. That is
how non-backwards-compatible changes to source formats have been done
in the past. A series of announcements on d-d-a with transition
availability etc. information would be good too.
Having said all that:
Now that are relying on gitish diffs, are there any plans to make
dpkg-source able to represent binary diffs, and file removals ?
(This is an alternative to my rsync proposal, which I have sadly put
on the back burner as it seems quite complicated to do all the things
everyone wants before it could be accepted. I still think `3.0
(rsync)' would be a good format - and it would suffer from fewer
compatibility problems, and fewer risks from immaturity of
dependencies, than `3.0 (quilt) [gitish]')
Thanks,
Ian.
Reply to: