[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: git packaging workflows



Hi Daniel,

please forgive me for brief, blunt, and perhaps somewhat irritated reply.


On Tuesday, 13 August 2024 9:34:54 PM AEST Daniel Gröber wrote:
> >   https://salsa.debian.org/onlyjob/notes/-/wikis/bp
> 
> Yeah, that doesn't work for me. I get anxious without a git repo :)

In the end simplest and most straightforward approach works the best.

Use git repo, but don't rely on it to build a package. 

You can build in dedicated build directory, and that don't have to be
the debian package repository.


> Since I'm still searching here's my git workflow requirements list:

Overly complicated workflow is impediment for collaboration and
co-maintenance.

Simple is really the better. The less distraction on packaging tools will
give you more capacity to focus on problems that need solving.


>  - patches-applied (just commit/cherry-pick, no manual debian/patches
> handling)

There is no way to avoid manual handling of patches. Exporting git commit
as a patch is trivial enough. "quilt" may be not the most advanced
patch management system, but it is certainly quite robust.


>  - allows preserving upstream history

Get upstream history from upstream. More often than not you won't need
upstream history, and certainly there is no need to mirror it on debian
infrastructure. It is most inconvenient when upstream history is
interleaved with debian package history. Keeping them apart is the best.


>  - "import" upstream releases from git

That is the most awful thing about GBP workflow. Sometimes it is not applicable, sometimes it does not work, when it works it works badly,
it comes with significant overhead plus risks of inconsistencies.
Many problems originate from storing upstream in debian packaging repo.

It is almost always redundant. As maintainer you have to make sure that
"debian/watch" works and that tarball workflow works first. If that works
then importing upstream into packaging git repo is redundant.


> I agree in principle but my solution does not involve giving up on git
> packaging tools entirely :)

Whatever works for you without adding complexity to your co-maintainers
is the best. I like "gbp dch --full" command -- perhaps the most (if not
the only) useful tool from git-buildpackage.


> However: I think your criticism on space/bandwith use is unfounded. Git is
> spectacularly efficient at packing history. Even when it isn't because
> there's just so much of it --depth=N is always there to only download a
> compressed tarball's equivalent of data but with git benefits.
> 
> I'd also like to point out that git is more useful for bandwidth constraint
> users because it does delta-transfers. Imagine downloading multiple
> versions of 0ad-data to do some archaeology.

Nonsense. It does not matter if instead of latest release you have to
download "well packed" history of all upstream releases ever packaged
in Debian. You should not have to do that when it is not necessary.

If you need archaeology then clone upstream repository, or download prior
releases from Debian.

Bandwidth is not the only, or most important concern. When you work on many
packages, repositories grow not only in space but also in numbers of files
and everything is getting slower. You'd notice when your repository grow to
have around 100,000 files so you do slow and CPU-intensive "git gc --aggressive"
and doing that on many repositories is tedious. 

Storing all upstream releases in "upstream" branch of packaging repository is
unjustifiable, even if that became common/normalised packaging practice.

On small packages it is a little pain, but on large and complex packages it is
a big pain, so big that certain packages can not be maintained in such manner.


> IMO every workflow should have documentation like dgit's dgit-maint-*
> manpages even when it's "trivial". Any one workflow may be, but Debian has
> *many* of them.

Only something very uncommon needs to be documented within package itself.

For everything else there is plenty of information and general-purpose
approach to building packages is best to document elsewhere, outside of
package (e.g. in wiki).

Remember that everything committed is technical liability (debt) that
takes time to maintain.


> Many prominent packages use it after all.

And many don't. So? Majority decision is rarely a most sensible one.


> IMO if alternate workflows want to have any success they need
> to be visible.

To whom? Isn't it a matter of attention? And sometimes it is a matter
of consensus or established practice within a team. 

Complicated git workflows violate principle of least surprise.

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Politics: the art of using euphemisms, lies, emotionalism and
fear-mongering to dupe average people into accepting — or even
demanding — their own enslavement.
 -- Larken Rose

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: