Re: Upstream tarballs with varying line endings
Paul Wise <pabs@debian.org> writes:
hi Paul,
> On Fri, Nov 22, 2013 at 2:17 AM, Felix Natter wrote:
>
>> This is not possible for all patches. For instance, Freeplane also has a
>> Mageia linux package and so due to the lack of a recent Mageia
>> libjgoodies-forms-java package, we cannot update upstream to the new
>> libjgoodies-forms-java...
>
> It is almost always possible to merge patches upstream or rewrite
> patches to make them flexible enough to merge upstream.
Unfortunately libjgoodies-forms-java 1.6 renames some classes so you
can't have a source code/patch that works with both 1.4 and 1.6...
> I'd suggest you don't need to wait for Mageia, they will update
> libjgoodies-forms-java when they have a need for that.
Yeah, I already told my "packaging colleague" to ask for that.
> BTW, you might want to add DEP-3 headers to your patches:
>
> http://dep.debian.net/deps/dep3/
I'll probably do that for 1.3.x.
>> It's not possible. We have decided that we want to stick with this git
>> line ending policy and that means that checkouts on Windows will have
>> CRLF line endings (I am part of upstream but I wasn't involved in the
>> discussion).
>
> Ugh.
>
>> So what solution would you prefer?
>
> Would it be possible to ensure only non-Windows users make release tarballs?
I'd rather not rely on that.
> Would it be possible to have a release process that produces two
> release tarballs, one with Windows line endings and one with normal
> line endings, no matter which platform it runs on?
Only with solution (1) below. The git checkout on Windows contains CRLF.
>> 1. integrate http://ant.apache.org/manual/Tasks/fixcrlf.html upstream
>> (generate tarball, extract, fix line endings, generate tarball)
>
> This sounds like the best option so far. Generating the tarball twice
> sounds a bit hacky though, is there no way to copy the files to the
> tarball dir, fix line endings and tar that? That is the usual way to
> generate tarballs for the build systems I'm familiar with, except the
> fix line endings step isn't needed.
>
>> 2. write a get-orig-source target that does the same?
>> If yes, shall I append "+dfsg1" to the version number?
>
> That could work if upstream doesn't want to be helpful but is usually
> frowned on by Debian.
>
> +dfsg isn't appropriate in this situation because you aren't repacking
> for DFSG-related reasons. We usually use +ds (Debian source) when
> repacking for other reasons.
Ok, then I will stick to (1).
>> => I guess both are possible are OK for Debian?
>
> Right, the second one not so much.
I agree.
> There is a third option you could use that I would prefer if an
> upstream fix doesn't work out:
>
> Searching for quilt patch line endings on the web found me this bug
> where it was pointed out you could just reimport the patches after
> every new upstream release using this command:
>
> QUILT_PATCH_OPTS="-l" quilt import thepatch
> http://bugs.debian.org/383431
Good point, but I'd rather fix this once and forever :-)
Thanks!
--
Felix Natter
Reply to: