[Debian-in-workers] Multiple RFSs - Splitting fonts-smc (was Re: Updating fonts-smc and FontForge update)

Balasankar C balasankarc at autistici.org
Tue Nov 15 06:08:42 UTC 2016


Hi,

On ചൊവ്വ 15 നവംബര്‍ 2016 11:13 രാവിലെ, Vasudev Kamath wrote:
> On Tue, Nov 15, 2016 at 10:48 AM, Balasankar C
> <balasankarc at autistici.org> wrote:
>> Hi,
>>
>> [I am subscribed to the list. Need not CC me in replies]
>>
>> On ചൊവ്വ 15 നവംബര്‍ 2016 09:39 രാവിലെ, Vasudev Kamath wrote:
>>> One more thing I noticed you stripped upstream folder using gbp but it
>>> will still be present in the upstream tarball. So your justification
>>> reducing size still does not hold.
> 
>> Are you sure? Because, I just tried cloning the repo and built the package using `gbp buildpackage`. The folder I skipped using gbp.conf was present neither in the
>> orig.tar.gz generated nor the upstream branch of the repo. My belief is that it is the orig.tar.gz file that gets uploaded to the archive. Or, am I looking in the wrong
>> location?
> 
> OK I might have thought filter only filter from master and not from
> upstream branch.
> Preferred way to repack is either manually or use standard tools like uscan.
> 
> And IIRC its always suggested to use copyright to document the repacking.
> 

Ok. I will document it in debian/copyright.

> 
>>> Additionally if you remove some
>>> portion from upstream README.source is not the place to mention.
>>> Correct way to do is use Files-Excluded: in copyright and provide if
>>> required repacksuffix in watch file.
> 
>> Is it accepted in copyright format 1.0 ? I read in the page UscanEnhancements[0] that the bug regarding that is still open. So, I feel it is better not to use it until it is
>> part of the specification, officially .
> 
> Really?. copyright format 1.0 was used for a long time before it got
> accepted. It  was refered as DEP-5 at the time.
> 
> A quick code search shows how many other packages are already using
> it, because uscan is already part of devscripts. [1]. So no I don't
> buy your argument on not using it because its not "yet" accepted.

I may have different views on specifying that we use Format 1.0 and then
violating it in the copyright. Anyway, I intend not to use it, because I will
be using gbp.

> 
> [1] https://codesearch.debian.net/search?q=Files-Excluded%3A+path%3Adebian%2Fcopyright&perpkg=1
> 
> 
>> Also, isn't Files-Excluded used to specify uscan to remove the files? Since I am already doing that with gbp.conf, do I need this field?
> 
> gbp is just a packaging helper, people might use dgit to prepare
> something for your package or some time in future people may start
> using git-dpm. Then how do you make sure, people will not miss it?. On
> the other hand uscan is common tool used by people to download new
> upstream source. (standard tool for the purpose).
> 
> 

I agree. But, as long as I am maintaining the package I intend to use gbp and
document its usage (in d/copyright). I think it is safe to assume that someone
else trying to modify the package will at least send a mail to its maintainer,
and this will be properly communicated. Also, if someone takes over the package
in the future, s/he it is their choice, like I did with dh and CDBS when I took
over the package.

PS: I have been usually using gbp along with uscan argument.

>>
>> Another doubt in the similar tracks is that, do I need to use a suffix? Because, I am removing something from upstream not because it is DFSG-violating, but because
>> to reduce the file size (assuming that argument holds). If I have to, what suffix should I use?
> 
> dfsg is used when you strip of non dfsg content, there are still other
> prefixes people use. May be searching other packages will enlighten
> you bit more on suffixes used in archive!.
> 

Ok. Let me dig a little bit more.



-- 
Balasankar C
http://balasankarc.in



More information about the Debian-in-workers mailing list