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

Re: opencpn (was: opencpn: binaries without source)



On 11/29/18 8:46 PM, Alec Leamas wrote:
> On 29/11/18 20:10, Sebastiaan Couwenberg wrote:
>> On 11/29/18 9:33 AM, Alec Leamas wrote:
>>> On 25/11/18 14:58, Sebastiaan Couwenberg wrote:
>>>>    Why is the get-orig-source target used? The bugreport mentioned is
>>>>    not clear.
>>>
>>> The short story is that a plain uscan doesn't work, and that this is a
>>> known problem. It seems to be related to large sources generated with
>>> something else than a recent gnu tar. The work-around is basically to
>>> unpack and repack with gnu tar at which point things can proceed as usual.
>>
>> Plain uscan will work with the release tags.
> 
> Not for me, uscan  --force-download  crashes after downloading the git
> repo.  I have reverted to the github template in the uscan manpage just
> to eliminate other errors:
> 
> opts=\
> "filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%opencpn-$1.tar.gz%" \
>     https://github.com/OpenCPN/OpenCPN/tags \
>     (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate
> 
> Using devscripts 2.18.7 on sid. Have you actually a working watch file,
> or other reasons to believe the bug report is bogus?

I never encountered repacking failures for GitHub tarballs, and we have
several packages that do that. Only they don't exclude as many files as
needed for a sane OpenCPN tarball.

uscan on stretch is also not able to repack successfully, so there is
something that makes the opencpn case different from the other GitHub
tarballs that don't trigger the issue.

>>>>    Why add an override for the javascript files when they can be
>>>>    excluded from the repacked upstream tarball?
>>>
>>> Because all other things removed are supported by build system patches
>>> which have been upstreamed. Patches for removing these files will never
>>> be accepted, and likely a pain to maintain.
>>
>> You don't need patches to remove those unused files, you add them to
>> Files-Excluded in debian/copyright.
>>
>> If the patches to use packaged versions of those projects won't be
>> accepted by upstream, mark them as Forwarded: not-needed.
> 
> They will not, full stop. And the maintenance problem is obvious. Do you
> still insist that using patches + exclusions in the tarball is a better
> idea than to just drop them in install? If sou, could you please expand
> a little on the motives?

Using Files-Excluded to strip files that are unused in the build and
cause lintian issues like those for minified javascript, pre-built
binaries and such, is the right thing to do.

Adding patches to use the packaged version of dependencies instead of
embedded copies is likewise the right thing to do. Marking to patches as
Forwarded: not-needed saves other time thinking about whether it needs
upstreaming or not.

Having looked at the content of the OpenCPN tarball and not been pleased
by what I saw, I'm staring to doubt whether packaging opencpn is worth
the effort. Perhaps it should stay out of Debian where it doesn't have
to conform to our standards. Having as many of its dependencies as
possible packaged is still valuable, as long as those projects are sane.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


Reply to: