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

Re: proposed MBF: packages still using source format 1.0



On 3/15/22 10:36, Ian Jackson wrote:
Lucas Nussbaum writes ("Re: proposed MBF: packages still using source format 1.0"):
As explained in https://lists.debian.org/debian-devel/2022/03/msg00165.html
I proceeded with the MBF for packages that match
not (debian_x or (vcs and vcs_status != 'ERROR' and direct_changes))
or, maybe easier to read:
(not debian_x) and ((not vcs) or vcs_status == 'ERROR' or (not direct_changes))

I did not file bugs for packages that are likely to use a VCS-based
workflow (category (2) in the mail pointed above, or in
https://udd.debian.org/cgi-bin/format10.cgi)

At least the following packages of which I am the maintainer or
sponsor were includined in the MBF, despite the fact that they are 1.0
native packages with Debian revision:

    its-playback-time
    spigot
    vm
    vtwm
    chroma

I picked one of these, spigot, at random.

Clearly the it aakes no sense to have filed bugs saying "please switch
to this other source format" when the other source format cannot
represent the package.

I don't see any reason that 3.0 can't represent the spigot package. It looks like a straightforward package. It seems to have an upstream:

The top changelog entry says "Merge from upstream".

debian/control points me to:
http://www.chiark.greenend.org.uk/~sgtatham/spigot/

That site has a tarball available. The Debian package is NOT using that as its .orig.tar.gz. It doesn't have a .orig.tar.gz, presumably indicating it was built built as a native package (even though it has a Debian revision), which is the issue under discussion. To be honest, had I stumbled across this package outside of this conversation, I would have been confused by this.

My understanding is that Debian values the idea of using the pristine upstream tarball. Granted, sometimes that goal has to yield to higher priority things, like DFSG compliance.

How do you feel about the pristine tarball concept?

--
Richard

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Reply to: