Re: Parametrizing more vendor variation into the origin files
Hi,
answering for Kali:
On Mon, 02 Mar 2020, Guillem Jover wrote:
> For these I'd like to ask the following. Is your derivative:
>
> a) using a pathname for keyrings following the pattern used by the Debian
> keyrings (for archive and members, see below)?
We only have the archive keyring, and it's named along the same
pattern, i.e. /usr/share/keyrings/kali-archive-keyring.gpg with
a symlink into /etc/apt/trusted.gpg.d/
> b) re-signing the archive indices or mirrors Debian's (in case of
> overlays instead of full binary rebuilds), so we need to inherit
> the archive keyrings from the parent(s) distribution(s)?
We have our own full archive, signed by our key, but it contains a mixture
of Debian unmodified packages and of kali-specific packages.
> c) re-signing source packages (.dsc) even when not modifying them, so
> we need to inherit the member/archive keyrings from the parent(s)
> distribution(s)?
No, we're not resigning source packages.
> d) using a backport version marker different than the ~bpoN+M one,
> if at all?
We used to have something specific when we were based on stable and had to
backport stuff regularly, nowadays we're based on testing and we seldom
have anything like this. But I regurlarly add a "~kaliX" when uploading a
package to Debian and to Kali at the same time (only the kali package has
the suffix so that it sorts before the debian package and it can be synced
after a while).
> e) using a bug closure marker different than the default «Closes:...»?
We don't have any way to close bugs through changelog uploads. I do put
"FS#xxx" references to make it clear that we're speaking of our FlySpray
bug tracker but usally I put an URL directly.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Reply to: