Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Chris Knadle <Chris.Knadle@coredump.us> writes:
> On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote:
>> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
>> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
>> > > No, I hereby start saying good by to 3.0
>> >
>> > I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also
>> > found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last
>> > few packages.
>>
>> I can't see any reason to use 1.0 anymore, ever.
>>
>> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
>> has a number of upsides. And working around quilt is simple:
>>
>> echo "single-debian-patch" >debian/source/options
>> echo "/.pc" >>.gitignore
>> echo "/debian/patches" >>.gitignore
>
> I'm confused concerning the above; the point of a VCS in this context is to
> track changes to the source package, and the patches are themselves important
> changes to the source package. If you have Git ignore the patches then Git
> doesn't have a complete view of the source package anymore. Why would you
> want to do that?
You're source VCS would be with the patches applied already. When
building the source package dpkg-source will simply create
debian/patches/debian-changes as the diff between your working directory
and the orig tarball every time. Same as it did create a diff.gz file
with 1.0 format.
>> and perhaps "rm -rf .pc debian/patches" in the clean target if those bother
>> you -- and you have all the goodies that come with the 3.0 format, with
>> getting none of quilt brain damage onto you. Suddenly, nothing conflicts
>> with the VCS you're using, nothing breaks bisects, nothing causes spurious
>> recompiles, etc.
>>
>> Except for nuking upstream debian/ dir which can mean a bit of lost work if
>> the upstream is sane (and can save some if they're not), the 3.0 format is
>> strictly better than 1.0.
>
> If debian/ is nuked then so is debian/patches, and if Git has been told to
> ignore debian/patches then it cannot bring those files back. Patching the
> source can be an effort especially concerning documenting why the patches were
> done and the source of the patches, so these seem like they'd be important to
> track rather than something to ignore.
Small misunderstanding here.
If you have a 1.0 format package that contains debian/ in the orig
tarball then the diff.gz will contain only the changes to the debian
dir.
In 3.0 (quilt) the debian dir is ignored when unpacking an orig tarball
and the debian tarball contains the full debian dir. The benefit is that
you do no longer need to repack the orig tarball to remove files from
the debian dir and changes upstream does to the debian dir are
ignored. The drawback is that changes upstream does to the debian dir
are ignored.
MfG
Goswin
Reply to: