Re: RFC: DEP-14: Recommended layout for Git packaging repositories
* Raphael Hertzog <hertzog@debian.org> [141114 12:34]:
> On Thu, 13 Nov 2014, Bernhard R. Link wrote:
> > * Raphael Hertzog <hertzog@debian.org> [141111 22:26]:
> > > Helper tools should usually rely on the output of `dpkg-vendor --query vendor`
> > > to find out the name of the current vendor. The retrieved string must be
> > > converted to lower case. This allows users to override the current vendor
> > > by setting `DEB_VENDOR` in their environment (provided that the vendor
> > > information does exist in `/etc/dpkg/origins/`).
> >
> > Is using the vendor you use git on a good default for the vendor code
> > you are currently working on? In my experience those two are quite
> > unrelated.
>
> Do you have a better default to suggest? In any case, having a default
> value is certainly better than not having one and forcing everybody to
> configure it in some ways.
I'm not so sure about that. Having a broken default can be more annoying
than not having a default at all.
> I try to work in Kali chroots when I do Kali work. It's true that
> it's not always the case but if there were real differences right now I
> would pay more attention or would ensure to have the proper environment.
Well, for test-building stuff and things like that going to the proper
environment is nice, but why having the need to have gitk and new enough
versions of your helper tools around everywhere?
> > > Version mangling
> > > ----------------
> > >
> > > When a Git tag needs to refer to a specific version of a Debian package,
> > > the Debian version needs to be mangled to cope with Git's restrictions.
> > > The colon (`:`) needs to be replaced with a percent (`%`), and the tilde
> > > (`~`) needs to be replaced with an underscore (`_`).
> >
> > Is there a previous case of encoding colons with percent signs?
>
> This is the current convention used by git-buildpackage and I believe the
> "%" has been picked because it's visually close to ":" (i.e. two dots/two
> circles).
>
> > If it is inventing a third way instead of using on of the existing ones,
> > is sounds like a bad idea.
>
> Do you suggest to use URL encoding? That's rather heavyweight for two
> special cases that can be easily mapped to other characters that are not
> used in version strings. And it would convert characters that do not
> need any special escaping currently.
No, I was refering to the many ways to encode. I was yet aware of
encoding 2:1-3~4 as
debian2-1-3_4
debian-2_1-3_4
debian-2.1-3.4
I guess using single letters as format identifiers in git-dpm's tag
specification was a bit optimistic...
> > Tags are only based on versions are also quite hard to shuffle around.
> > I'd strongly suggest adding the name of the source package to those,
> > otherwise accessing multiple packages in on repository causes a big
> > mess. (git keeps branches in the per-origin "remote" namespace when
> > fetching stuff, tags only have one global namespace, local and remote).
>
> I don't think this makes sense. The common case is a single software per
> git repository. If you have multiple software, then the git way is
> to use git submodules. If you have an upstream that doesn't follow those
> conventions, then it's a good reason to not follow DEP-14 for the tagging
> of your Debian releases.
While having a repository hosting multiple projects permanently makes in
many cases not that many sense (though I sometimes prefer it for some
small stuff, as it allows to make/update a mobile backup with a single
git command), cherry picking commits from other repositories in git
to my knowledge requires fetching at least part of that history in your
current working repository. When fetching too much by mistake the global
nature of tags can make quite a mess.
> > > Native packages
> > > ===============
> > >
> > > The above conventions mainly cater to the case of non-native packages,
> > > that is when the upstream developers and the package maintainers are
> > > not the same set of persons.
> > >
> > > When upstream is Debian (or one of its derivative), the upstream vendor
> > > should not use the usual `<vendor>/` prefix (but all others vendors should
> > > do so). The main development branch can be named `master` instead of
> > > the codename of the target distribution (although you are free to still
> > > use the codename if you wish so).
> >
> > Does native here mean a native package or a package developed primarily
> > for Debian (which can also use a non-native packaging)? This paragraph
> > seems to mix those two concepts quite a bit.
>
> Yes it mentions both concepts. I tried to word it in a way that is clear
> enough though. If you find some parts ambiguous, let me know which one
> or suggest a better wording.
Perhaps s/If upstream is Debian/If the package uses the native packaging format and upstream is
Debian/ ?
> I tried to improve this:
>
> @@ -175,9 +177,8 @@ a byte-for-byte copy of the upstream tarballs, this should be done in the
> Native packages
> ===============
>
> -The above conventions mainly cater to the case of non-native packages,
> -that is when the upstream developers and the package maintainers are
> -not the same set of persons.
> +The above conventions mainly cater to the case where the upstream
> +developers and the package maintainers are not the same set of persons.
>
> When upstream is Debian (or one of its derivative), the upstream vendor
> should not use the usual `<vendor>/` prefix (but all others vendors should
> @@ -185,11 +186,12 @@ do so). The main development branch can be named `master` instead of
> the codename of the target distribution (although you are free to still
> use the codename if you wish so).
>
> -When the package is shipped as a native source package, the concept of
> -"upstream sources" is irrelevant and the associated `upstream/*` branches
> -are irrelevant too. Note that even if the upstream vendor ships the
> -package as a native package, the downstream vendors can still can opt to
> -package it in a non-native way.
> +When the package is shipped as a native source package (i.e. a single
> +tarball with no differentiation of the upstream sources and of the
> +packaging files), the concept of "upstream sources" is irrelevant and the
> +associated `upstream/*` branches are irrelevant too. Note that even if the
> +upstream vendor ships the package as a native package, the downstream
> +vendors can still can opt to package it in a non-native way.
How about
The above conventions mainly cater the case where development of the
software ("upstream work") and packaging the software are kept separate.
If using the "native" source package formats (i.e. those without a .orig.tar
file like "3.0 (native)"), then the usualy `<vendor>/' prefix can be
omitted. upstream/ branches and tags usually make no sense in this sitation.
Note that even if the upstream vendor ships the package as a native package, the
downstream vendors can still can opt to package it in a non-native way.
> > > Managing debian/changelog
> > > -------------------------
> > >
> > > This DEP makes no specific recommendation on how to manage the Debian
> > > changelog. Some maintainers like to use tools like `gbp dch` to generate
> > > the changelog based on Git commit notices, others edit the file manually
> > > and use tools like `debcommit` to reuse the changelog entry in the
> > > Git commit.
> > >
> > > Helper tools should however configure the Git repository so that merges
> > > of the `debian/changelog` file are handled by `dpkg-mergechangelogs` as
> > > this will make it much easier to merge between different packaging
> > > branches.
> >
> > Ugh. Please do not encourage tools to pester with my git config.
> > (Perhaps this want meant as something to do when automatically creating
> > a repository for you?)
>
> Yes, I meant it mainly for things like "gbp clone".
I guess rewording that to make it more clean might be helpful.
--------
What you haven't replied to is my comment first comment about upstream
branches, which I in respospect think was also not worded very well.
Let me retry:
I think such a document would do well to not say much about upstream
branches or imply how they should be managed.
How to best handle them depends heavily on upstream, your preferences
and the packaging tool you use (I think svn-^H^H^H^Hgit-buildpackage
makes some use of them, but otherwise they are mostly a burden.).
Statements like "Helper tools should detect when the upstream version
imported is lower than the latest version available in `upstream/latest`
and should offer either to create a new branch (based on the highest
version available in the history that is still smaller than the imported
version) or to pick another pre-existing upstream branch." seem to imply
some very specific upstream system (where development is linear or in
a way a helper tool could automatically determine it) and not helpful
in the general case.
git-dpm creates some git branch head for the upstream branch. But I
realized that I usually remove this git branch manually directly afterwards
whenever it creates it. Having it around as a permanent branch (as
opposed to as a temporary head) simply has no advantages but is annoying
as it gets out of sync so offen (git simply has no support to keep
different branches in sync even locally, and remote the situation is
even worse).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Reply to: