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

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format



On 05/17/2012 04:52 PM, Gergely Nagy wrote:
> 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?
> 
> Git does have a complete view. What the above does, is tell dpkg-source
> to fold any changes made to the upstream sources into a single
> patch. Since the git tree already has the patches applied (with upstream
> sources on a different branch, most probably), it has a full view.
> 
> This basically folds whatever patches the git tree has over upstream,
> outside of debian/ into a single file. That's about it. Since that file
> is generated, it has no business staying in git.

Doing that is the most stupid idea ever. All it does is to ensure that you
package can't be NMUed sanely and that people who need to work with the sources
and your patches for whatever reason have to clone your git, which might be not
available or just too large for them to download - so at the end changes are
high that they end up with a largish unreadable patch, similar to the mess we
get from Ubuntu sometimes.
The only thing that makes sense would be to use git-format-patch to export your
patches to debian/patches and list them in the series file. Or use gbp-pq, which
was made exactly for that.

[...]

>> 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.
> 
> The reasons can - and should be - documented in git. Granted, that does
> not transfer to the debianized source package, which is unfortunate, but
> it's still better than fighting with integrating quilt with a VCS (in
> which case, everyone with a higher number of patches would go back to
> 1.0 and custom patching systems and ignore every other benefit of 3.0,
> because quilt and VCS generally don't play nice together).


Which again requires people to find and clone the git instead of just looking
what we ship on our mirrors and discs. Remember, there are people without (fast)
internet, they might not be able to clone your git, or not be allowed to do so
for whatever reasons.


-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


Reply to: