Re: More flexible source format (was Re: gdb is broken?)
> I think a lot of people would love to see this. Red Hat already has
> a multiple-patches source format, which has proven very handy for us
> (to extract specific fixes).
Yep, I had the RedHat source format somehow in mind. I don't want to
copy it, but I like the idea of strictly pristine sources plus a set
of patches. However, I have only vague ideas until now how the new
format should look like. Here are those ideas:
- Source packages should still consist of three files: the .dsc, an
.orig.tar.gz, and some file holding all Debian specific stuff. I
think this should be a tar file, too, but I haven't invented a good
extension for it yet. (Using .tar.gz again might cause name
conflicts, and might confuse some tools that scan through the
source directories manually.)
- There should be something to handle .orig.tar.gz files that do not
unpack into a subdirectory. (So that also such sources can be
pristine.)
- The Debian tar file contains the debian/ subdir, the set of
patches, and some metainformation for each patch.
Representing the debian dir as a tar file has the advantage that
file permissions inside it are preserved automatically, and also
symlinks and subdirs become possible without any headaches.
- The collection of patches needs to be ordered somehow (maybe prefix
filenames with a 3-digit serial number), so that they can be
applied in proper order.
- Meta-information to patches can include:
+ architectures to which they apply (best including a notation for
excluding some archs)
+ same for operating systems (we already have Hurd besides Linux)
+ a list of additional changes that cannot be represented in a
diff file: permissions of new files, symlinks
+ maybe some other conditions that restrict applicability of a
patch (which ones?)
The current dpkg-source can be extended for the new format in a
backwards-compatible way, i.e. it recognizes the current format can
still can handle it. This way packages can switch to the new format
any time they like to.
Furthermore, there should be a tool that builds a new patch based on
the current unpacked sources and the previously available diff. That
way it should be easy to modify some files and make an additional
patch out of these changes. And also nice would be a tool that assists
maintainers in splitting the current .diff.gz file into separate
patches.
If some people are interested in further developing these ideas, we
could either create a mailing list somewhere, or ask Joey if he makes
a new debian-* list for us. Please don't let us discuss all the
technical things here on debian-devel, as this list already has enough
traffic and I usually only have a glance at it.
Roman
Reply to: