Control: retitle -1 RFS: scala-mode-el/1:1.1.0+git20240113.4c6d636-1 [RC] 
[Team] -- Emacs major mode for editing scala source code

Xiyue Deng <manp...@gmail.com> writes:

> Hi,
>
> Xiyue Deng <manp...@gmail.com> writes:
>
>> Nicholas D Steeves <s...@debian.org> writes:
>>
>>> Hi,
>>>
>>> Paul Wise <p...@debian.org> writes:
>>>
>>>> On Mon, 2023-12-04 at 02:28 -0800, Xiyue Deng wrote:
>>>>
>>>>> I think dh_auto_clean is the right place, because the build failure is
>>>>> because that the clean target requires the existence of
>>>>> scala-mode-pkg.el, which is generated by Cask.  As we don't have Cask,
>>>>> we need to provide this before dh_auto_clean runs.
>>>
>>> The generation of this metadata, and file, is one of dh_elpa's primary
>>> functions.  See the section of the dh_elpa man page that discusses
>>> DEB_VERSION_UPSTREAM.
>>
>> Ah I see what you mean: as long as dh_elpa can detect the version
>> correctly we don't need to provide an actual *-pkg.el file and can just
>> let dh_elpa generate it, which also avoids the potential policy
>> violation Paul pointed out.
>>
>> So now I make override_dh_auto_clean to call dh_elpa to generate this
>> file for use.  However, as the generated file is "buried" pretty deep in
>> the generated directory, the command becomes pretty long, but it works.
>> Admittedly that requiring a generated file during clean is pretty exotic
>> and I haven't encountered it elsewhere (yet) which is good.
>>
>> New handling strategy pushed to team repo.  PTAL.
>>
>>>
>>> Read Policy §4.9 closely; Cask cannot be used.
>>>
>>> Grep the buildlog for "dh_" and if you'd like to see a more
>>> comprehensive list of applicable entry points in the sequence, try
>>>
>>>   $ dh binary-indep --no-act
>>>
>>> It's also worth reading the dh man page.
>>
>> Ack.
>>
>>>
>>>> I think it is against ftp-master rules to have generated files
>>>> present that can't be built using only tools from Debian main.
>>>
>>> Yes, and thank you for bringing this up.
>>>
>>>> So I think you would need to package Cask first?
>>>
>>> Cask is not relevant nor needed, and dh_elpa is used.  Whenever this
>>> topic comes up on IRC, new contributors are briefed and are additionally
>>> referred to the RFP for Cask, where the unsuitability of this type of
>>> tool for Debian packaging is discussed (#837922).  It's also worth
>>> noting that dh_elpa was written by people by current and/or past members
>>> of the Debian TC.
>>>
>>> Xiyue Deng <manp...@gmail.com> writes:
>>>
>>>> Cask and similar tools like Eask and Eldev are tools that automatically
>>>> install dependencies of an Emacs addon package, which doesn't use and
>>>> circumvents the system package management.  I think the Emacsen team
>>>> chooses not to package those tools and prefers using dh-elpa for the
>>>> job, and may override build target to avoid using those tools.
>>>
>>> If you're familiar with the concept of "hats", then when you're working
>>> on debian/* you need to put on your Debian packaging hat, and when
>>> you're working on !(debian/*) you use your upstream
>>> development/debugging/packaging hat.  These tools are not relevant to
>>> Debian packaging and referring to them is not useful for describing
>>> packaging problems or decisions; there will always be a more direct and
>>> useful description.
>>
>> I think those external tools are not completely irrelevant but just in
>> the sense that we do it the Debian way.  Usually they provide two types
>> of functions: 1) automatic dependency management, and 2) automatic file
>> generation required for testing and distribution through elpa.  In
>> Debian, the former is handled by apt, and the latter by dh_elpa, and we
>> take effort to make sure they behave the same.
>>
>>>
>>> Cheers,
>>> Nicholas
>>>


It looks like the bug was archived so the previous mail didn't reach
BTS.  So unarchived, reopened, and retitle the bug with newer snapshot,
and also resending the following from previous message.

>
> With the release of the new policy version, I have done some more clean
> up to the package and update team repo and mentors.  PTAL.  TIA!

-- 
Xiyue Deng

Attachment: signature.asc
Description: PGP signature

Reply via email to