Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi Gergely,
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`.
And if upstream uses v1.2.3 we should use debian/v1.2.3-1?
Do you know many upstreams using "foo-1.2.3" as tags?
I must say that I don't see the value that this brings. It might be
aestethically more pleasant when browsing the list of tags but for
everything else, it's just more painful. We lose the ability to
easily identify the commit of a given Debian release (instead
of a simple lookup operation, you have to scan all existing tags, and even
then if you have no clear mapping with the Debian version, you can't be
sure that you will find the correct tag).
Thus I don't think that this is a good idea.
> Raphael> It is also important so that contributors are able to use the tool of their
> Raphael> 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.
>
> 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.
I'm open to that, but IMO the only case where there are very good reasons
are the case where the upstream data is really huge and not easily
patchable anyway (i.e. the case of openarena-data that Simon Mc Vittie
described in https://lists.debian.org/debian-devel/2014/08/msg00582.html).
Are there other reasons that you consider good enough to impose the above
penalties on other possible contributors (i.e. making it impossible to use
gbp pq or similar tools to update debian/patches)?
> 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.
Can you elaborate on how it was superior?
> In short, I'd suggest having the DEP document both layouts, and
> recommend using one of them, while also recommending to document it in
> debian/README.source.
I have put this for now:
@@ -195,6 +203,12 @@ choice to update the debian/patches quilt series: multiple helper tools
need the upstream sources in Git to manage this patch series as a Git
branch.
+When you have good reasons to only store the `debian` packaging directory
+(for example when the uptream sources are really huge and contains mostly
+non-patchable data), you can do so but you should then document
+this in `debian/README.source` along with some explanations of the tool
+to use to build the package.
+
Managing debian/changelog
-------------------------
Does that sound better?
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
Reply to: