Re: Notes from the DebConf Source Format BoF
* Russ Allbery <email@example.com> [100811 05:27]:
> If you're implementing 3.0 format, please don't hard-code the extensions that
> you "know" will be found in source packages, because as we add additional
> files listed in *.dsc, we may add other types of files.
Please be carefull with adding new extensions. Those files end up in
.changes files and in the pool/. The extensions of those files are
already hardcoded in many places (partly because of oversight, partly
because of missing imagination, partly because it is really hard to
catch common errors if you have no idea what you are dealing with).
> One issue with 3.0 (quilt) is that when you check it out when it's
> maintained in a VCS, you have two choices: commit the .pc directory and
> files, or leave it out and then have to run some magic after you fetch the
> VCS in order to work on the quilt patches. (Assuming you check in to your
> VCS the results of having all the patches applied.)
If you have a patches source and no .pc that means:
if you just change stuff and call dpkg-source (e.g. via
dpkg-buildpackage), a new patch on top will just be generated.
And you can always use the method the patches were generated from. The
only thing that does not work is working with quilt on the already
existing patches easily. (I personally think quilt is just missing an
option to be initialized on an already patched working directory. That
would also could have avoided the "create .pc as dpkg-source -x" madness).
> - Why don't you just check in with patches not applied?
> * You can do this with a rebased patch branch, but then you don't get
> history on modifications to the patch.
You can merge the the different states of the patched branch into your
main branch. That way you can rebase it and still have the old state
around. (That is what git-dpm does).
Bernhard R. Link