Hello,

On Thu 18 Apr 2024 at 06:24pm -07, Xiyue Deng wrote:

> Sean Whitton <spwhit...@spwhitton.name> writes:
>
>> control: tag -1 + moreinfo
>>
>> Hello Xiyue,
>>
>> Please explain the autopkgtest_keep change.  Remember that autopkgtests
>> are to test the installed package.  If you need to keep the .el files,
>> it must be for some reason other than because the test suite actually
>> just tests those.
>>
>
> I think this is another example of buttercup tests that requires source
> .el files to run.  I'll probably open a bug on buttercup to see whether
> this is required for buttercup.  Meanwhile I think it'd probably be
> better to just disable autopkgtest as the tests are already run as part
> of the build process.

I agree.  It is important not to use autopkgtest_keep without being sure
it's the right answer.

>> You've removed the Built-Using with the justification that it's an
>> arch:all package, but that doesn't make sense; Built-Using is for
>> licensing reasons, and may well be applicable to an arch:all package (I
>> think this came up before with one of your uploads?).
>
> Ah I was following the suggestions of Lintian which said it cannot be
> used by arch:all packages which is probably wrong.

See #999785.

> On the other hand, on a closer look at the policy regarding
> Built-Using on section 7.8[1], it has the following passage:
>
> ,----
> | This field should be used only when there are license or DFSG
> | requirements to retain the referenced source packages. It should not be
> | added solely as a way to locate packages that need to be rebuilt against
> | newer versions of their build dependencies.
> `----
>
> I checked that lua-mode is of GPL-2+[2], and of all its dependencies
> lua5.3 is of MIT which is compatible with GPL, and the rest are all GPL
> 2+ or 3+, so I don't see a license or DFSG need to add this Built-Using
> requirement.  The change was introduced in [3] but it was part of the
> modernization effort so there is no direct justification of adding the
> field.  May be I'm missing something here?

It sounds like it shouldn't have been introduced.  So you can remove it
based on your reading of Policy, and briefly note your reasoning in
d/changelog.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature

Reply via email to