>>>>> "Raphael" == Raphael Hertzog <hertzog@debian.org> writes:
Raphael> Hi Gergely,
Raphael> On Wed, 12 Nov 2014, Gergely Nagy wrote:
Raphael> When releasing a Debian package, the packager should create and push
Raphael> a signed tag named `<vendor>/<version>`. For example, a Debian maintainer
Raphael> releasing a package with version 2:1.2~rc1-1 would create a tag named
Raphael> `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with
Raphael> version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should
Raphael> point to the exact commit that was used to build the corresponding upload.
>>
>> Mmm... I disagree here too. I think following upstream tagging
>> conventions would be the way to go here. So if upstream uses
>> `<package>-<version>` tags, then debian releases would be tagged like
>> `debian/foo-2%1.2_rc1-1`, if upstream is `foo-1.2rc1`.
Raphael> And if upstream uses v1.2.3 we should use debian/v1.2.3-1?
Yes.
Raphael> Do you know many upstreams using "foo-1.2.3" as tags?
syslog-ng and syslog-ng-incubator uses foo-1.2.3, so does a few of my
own (libmongo-client, riemann-c-client), and I came across a few others,
but I haven't been keeping track.
Raphael> I must say that I don't see the value that this brings. It might be
Raphael> aestethically more pleasant when browsing the list of tags but for
Raphael> everything else, it's just more painful. We lose the ability to
Raphael> easily identify the commit of a given Debian release (instead
Raphael> of a simple lookup operation, you have to scan all existing tags, and even
Raphael> then if you have no clear mapping with the Debian version, you can't be
Raphael> sure that you will find the correct tag).
It's just two lookups, but I see your point. Sticking to the more common
v$VERSION as a recommendation is good enough.
>> I'd like to note that there are very good reasons for a debian-only,
>> overlay-style packaging repository too. This section should, in my
>> opinion, at least acknowledge that, and briefly mention it as an option.
>> I find it a bit sad that it was outright discouraged.
Raphael> I'm open to that, but IMO the only case where there are very good reasons
Raphael> are the case where the upstream data is really huge and not easily
Raphael> patchable anyway (i.e. the case of openarena-data that Simon Mc Vittie
Raphael> described in https://lists.debian.org/debian-devel/2014/08/msg00582.html).
Raphael> Are there other reasons that you consider good enough to impose the above
Raphael> penalties on other possible contributors (i.e. making it impossible to use
Raphael> gbp pq or similar tools to update debian/patches)?
My reason for going debian-only is that I'm doing far more packaging
work, than upstream. I hardly ever touch upstream, to be honest. But I
actively maintain half a dozen packaging branches, and do merges between
them. This would be a big headache if upstream sources were there,
because some of these branches belong to different upstream versions.
>> For the record, I used to hate that style, and was an advocate for
>> storing upstream sources in the repo too. Then I started maintaining ~6
>> packaging branches: three upstream versions, two packaging branch
>> variants of each. The overlay style proved to be far superior in this
>> case.
Raphael> Can you elaborate on how it was superior?
See the use-case above. It was superior because I could do merges much
easier, my history looks nicer, and upstream can use my debian-only repo
as an overlay too, to build their own unofficial packages. It's very
useful not only for the case when you have numerous active packaging
branches, but in the case when you work with upstream on unofficial
packages, too.
With an overlay, they can just include it as a submodule, or use
git-buildpackage with its overlay support, on top of pretty much any
codebase they want, with minimal modifications.
Raphael> I have put this for now:
Raphael> @@ -195,6 +203,12 @@ choice to update the debian/patches quilt series: multiple helper tools
Raphael> need the upstream sources in Git to manage this patch series as a Git
Raphael> branch.
Raphael> +When you have good reasons to only store the `debian` packaging directory
Raphael> +(for example when the uptream sources are really huge and contains mostly
Raphael> +non-patchable data), you can do so but you should then document
Raphael> +this in `debian/README.source` along with some explanations of the tool
Raphael> +to use to build the package.
Raphael> +
Raphael> Managing debian/changelog
Raphael> -------------------------
Raphael> Does that sound better?
Better, but this still leaves it as a second-class citizen, with which
I'm not entirely happy with.
--
|8]
Attachment:
signature.asc
Description: PGP signature