On Tuesday, 13 May 2025 3:03:10 PM AEST Otto Kekäläinen wrote: > That is subjective.
When comparing two different approaches to maintenance, is it really that "subjective" to produce informed judgement about which one is better? My "subjective" conclusion is supported by decade of intense package maintenance of broad range of Debian packages. > If a new maintainer is to check out that > repository and build it, I suspect they will struggle. Only if they are incompetent and only can build a package with assistance of GBP. Such maintainers typically don't know how to prepare NMU, and/or fix a bug without access to git repository. Actually, GBP repo layout have much greater surface for struggle. Problems with GBP layout happen all the time and they are often difficult to fix. What is there to struggle with non-GBP package build workflow? https://salsa.debian.org/onlyjob/notes/-/wikis/bp > Also as soon as > you run into upstream bugs and either fix them in Debian and want to > submit it upstream, or find that they are already fixed in upstream > main branch or a pending PR/MR and you want to cherry-pick them, you > can't use any git commands but need to do manual patch management. Nonsense. There are simple methods to with with such situations, starting with wget-ting patch directly from Github, or format-patch-ing from local branch following upstream, or exporting patch from git GUI (e.g. "gitg"). Remember that "upstream" branch in GBP layout is often just redundant import or tarball by "gbp import-orig". > That structure will also fail to build with the Go team CI. If you > look at https://salsa.debian.org/go-team/packages/gocryptfs/-/pipelines > you see that the CI actually *never passed*. You are confusing different issues. It "never passed" because repository was in a mess, and I had no capacity to fix everything, working under assumption that someone else still cares for the package. > The structure you now have *does cause overhead* - it is just that > you don't bear it yourself. No. GBP repo layout cause greater overhead than my elegant, minimalistic approach. I shall be happy to switch CI to use my own Gitlab Runner infrastructure, if you are concerned by overhead to Salsa's Runners. (I'd like to think that my Runner relieves some overhead from Salsa, at least in the projects configured to use it.) > Only time the CI passed was when Felix Lechner fixed the repo on > branch https://salsa.debian.org/go-team/packages/gocryptfs/-/tree/debian, > but seems that was then abandoned and now you have two 'head' branches > on the repo. Yes, there was an issue with GBP layout, that's why I did the work in "master" branch". > Anyway I assume you have your locally optimal workflow that you once > learnt, and are probably new keen to learn a new workflow, This is ridiculous and even outrageous. I use GBP layout in teams where it is appropriate, but I don't like it, because it creates redundant overhead, and it is not suitable for sophisticated packages, MUT packages, etc. Here is my incomplete overview of problems with GBP layout: https://salsa.debian.org/onlyjob/notes/-/wikis/no-gbp Also let me remind you that I have worked on over 12 times(!) more packages than you did, hence I know a fair bit about those things. That "new workflow" is not always better as it comes with cost of added complexity. > so I won't spend more time on it nor on cleaning up of fixing your repo. As you wish, but there is nothing to fix (apart from removal of redundant "debian" branch"). Santiago kindly fixed CI so now the repo is in OK state. You can have your "upstream" branch, or even push it to repo -- I don't care because I don't use "upstream" branch at all, always building from downloaded tarball. > I don't want to own the "overhead" - you should as the repo layout > owner take care of maintaining it yourself so it is clean and aligned > with what you want. I don't understand what "overhead" you are talking about... > > IMHO "origtargz" utility makes "pristine-tar" obsolete. > > It downloads the tarball purely based on URL, without using any > verification / security features. As this is a security tool and the > maintainer understands supply-chain security, they over signed > tarballs at https://github.com/rfjakob/gocryptfs/releases/tag/v2.5.4. > If I were to maintain this package in Debian, I would definitely use > both pristine-tar and upstream signature verification. Your comment > assuming that origtargz, that has no security features whatsoever, > somehow obsoletes a tool specifically designed for supply-chain > security, makes it seem that the gap between your and my expectations > is wide, so I probably should just look away and not try to care about > this package. Nonsense. "origtargz" uses various methods of obtaining tarball, including generating it from repository. However numerous problems originate from situation where orig-tarball generated from repo is not binary identical to already uploaded one (or to actually released tarball, like in case when "uptream" branch is broken, incorrectly tagged, tampered with, etc.) To avoid such problems it is best to ignore "pristine-tar" and "upstream" branches, and build from orig-tarball obtained from Debian mirrors (from where "origtargz" conveniently fetches, when possible), or get orig-tarball by "uscan" command (that "origtargz" invokes automatically), using signature verification whenever it is codified in "debian/watch". P.S. If you insist I can align with your preferences, as it is not all that important to me how "gocryptfs" package repository is structured. Since I can spare only so little time for it, I'd say adopt the package if you care about it, having git repository layout of your preference, and yours truly might occasionally come back with contributions that don't disrupt established layout. -- All the best, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently. -- Friedrich Nietzsche
signature.asc
Description: This is a digitally signed message part.
