Le 2025-01-07 11:29, Marco d'Itri a écrit :
On Jan 07, Raphael Hertzog <hert...@debian.org> wrote:
This change basically adds the recommendation to use "upstreamvcs" as
the
name of the "git remote" to access the upstream repository and it also
Like many others, this looks like a gratuitous change for change's
sake.
Countless packages have been using "upstream" for years, but apparently
it is not perfect enough and somebody had to invent a new name.
Let's say upstream name their release tags like "1.2.3". That's valid
and that happens.
In your Debian packaging repository, after importing that release you
now have a tag named "upstream/1.2.3" if you follow the proposed
convention or use some existing tooling with its default configuration.
Let's now assume that your upstream remote is named "upstream", as is
common practice (I do that too).
git checkout upstream/1.2.3
--> the tag from upstream or the tag from your import? Nominally that
should be the same content, excepted that there are many projects that
repack sources, and the tooling will always generate a different commit
anyway. The different name is to resolve this ambiguity.
I still believe that this is trying to codify a lot of pratices (e.g.
the obsession with pristine-tar) which are not widely accepted.
This DEP only codifies the branch name (and btw forgets to mention
pristine-lfs) if you choose to use it, and it's not even pushing you to
use it in any way.
This DEP is the result of an echo chamber and is the consensus of the
few people debating it on salsa.
You are free to join or discuss it here. That DEP has been online for
some years now, it's not exactly happening in the hiding.
+The codename can also be prefixed with the version so that branch
names
+are correctly sorted by age of the target release in the list of
available
+branches. Examples: `debian/12-bookworm`, `debian/11-bullseye`,
+`ubuntu/24.04-noble`, `ubuntu/22.04-jammy`.
So to gain optional sorting now you lose the benefit of being able to
mechanically determine the branch name? This is beyond silly.
This ability is not lost, it just needs a bit more logic or input data
to match both naked codenames and versioned codenames. The tradeoff
seems reasonable.
WTF? I say instead that in the modern worlds it is a best practice to
have the packaging repository as a branch of the upstream repository.
Could you please give us a few examples of projects where that already
works out-of-the-box, ie the package is built and uploaded to the
archive exactly as provided by upstream, debian/changelog and all?
Again, trying to promote personal preferences to a standard.
That's just a set of recommendations, not policy. You are free not to
follow them. In the meantime many packages already adopted some of the
proposed conventions so maybe just expect to be asked questions more
often about your own personal preferences, but if they are reasonable
that should not be much of an issue, and if that happens often enough
you may want to publicly document them somewhere to avoid repeating
yourself.
Cheers,
--
Julien Plissonneau Duquène
