Re: Best practices for Debian developers who are also upstreams?
On 2020-02-18 23:14:14, Simon McVittie wrote:
> On Tue, 18 Feb 2020 at 15:47:17 -0500, Antoine Beaupré wrote:
>> The tricky part here is generating a new version without mangling
>> debian/changelog all the time. I haven't found a great story for that
>> that works with git, but maybe you can generate syntetic commits to fake
>> a new Debian package version in CI.
>
> I think the way to do this is to have an uncommitted change to d/changelog
> when you do your build, and choose your CI version numbers carefully so
> that they interleave correctly with "real" version numbers.
> https://gitlab.collabora.com/smcv/deb-build-snapshot/ (currently on my
> employer's infrastructure, but I'll probably move it to Salsa at some
> point) is designed for this workflow.
My trouble with doing that by hand is when I change the git-repo,
git-buildpackage and friends complain about uncommitted changes.. :) I'm
sure there are simple ways around that, but that was the blocker I
remembered back then.
> The version-number-generating part, deb-git-version-gen, implements the
> careful choice of version numbers and has been split out into a separate
> script which I might propose for inclusion in devscripts at some point -
> it should be feasible to run as a git-buildpackage hook or similar,
> and can either run dch itself, or output a simple version number or a
> blob of JSON describing the package's versioning (the latter includes
> some suggested arguments for dch).
That would be really nice.
>> Also, this is not for everyone: it makes it hard for Debian folks to
>> send updates to the git repository (because it might not be on
>> debian.org infra)
>
> This seems particularly weird for native packages, which are supposedly
> "written specifically to be a Debian package" (Policy §5.6.12).
I have always found the wording and context around native packages to be
really weird. Aren't all Debian *packages* written specifically to be
debian packages? :)
(I know the actual wording is "a piece of software was written
specifically to be a Debian package"... So yes, I'm being facetious
here.)
I think that restriction should be lifted, personnally. Using native
packages has made my job as an upstream and a Debian developer much
easier even if the tools weren't specifically written for inclusion in
Debian. There are many cases of such packages that don't respect policy
and I wonder if policy should adapt rather than changing that practice.
I also find it quite ironic to think about this provision in the context
where a lot of software specifically written for Debian is actually
*not* packaged in Debian itself. Instead it's being deployed through
other means on Debian.org infrastructure. So the prime use case of
native packages is not being really used in the first place. ;)
[...]
>> and inversely it makes it hard for "upstream" to make
>> a release if they're not Debian developers.
>
> This was a practical problem when Joey Hess left Debian: ikiwiki was a
> native package, with no release procedure other than uploading it to
> Debian, and I became a single point of failure for security releases
> because I was suddenly the only person with both ikiwiki commit access
> and Debian upload rights.
>
> (I later disentangled it so that upstream releases are just git tags
> pointing to a native package, and the Debian packaging is non-native.)
I have not found the switch between native and non-native to be that
problematic, personnally. It's something that needs to happen on
upstream or debian team changes, but it can be done reasonably
easily. Or at least it's easy enough that it's not a disincentive to use
native packages when you can.
A.
--
All governments are run by liars and nothing they say should be
believed.
- I. F. Stone
Reply to: