On Wednesday, 28 April 2021 11:00:19 PM AEST Antoine Beaupré wrote: > Yeah, that's what I did from buster, but I'm a little hesitant in > sourcing packages directly from unstable, because then there's no "event > horizon" when which the package becomes ... well, stable. I'm with you. I do my best not to break it because I use the package in sensitive environments. Careful use "of experimental" can protect from breakage in "unstable", to some extent. > > I like simple workflow resembling the following: > > https://salsa.debian.org/onlyjob/notes/-/wikis/bp > > It would be helpful to have a link to those notes (or a TL;DR:) in a > README.source in the source package... Why? Just because some developers forgot how to build a Debian package without GBP? Once that was a common knowledge and still should have been. > Well that's what git reset is for. :) More needless operations and still a bloat of the git repo size... > Hum. That's a rather long read and I'm not sure I want to get into a > "how my way of building Debian packages is better than yours". It seems > we all have our ways and while that's unfortunate, I guess that's life. I'm not asking you to read. Personally I always strive to learn how to make things better. I've found that GBP workflow is full of problems and that it does not really solve any problem either. Wouldn't you like to know? Besides it is not just "my way of building is better" (it may or may not suit you). It is that GBP is at least unproductive and difficult to use with packages that "vendor" extensively, and in some occasions (e.g. docker.io) GBP does not work at all. With several packages we only started to make progress when we stopped using GBP's repo layout. > The key point, in my mind, is that each package should explicitly > document its own workflow clearly somewhere, and that wasn't done in > this specific package. I looked at the existing branches from Salsa and > they *did* have the upstream/pristine-tar/master so I assumed gbp was > the right way to go forward. I'm happy to use another workflow. Make sense. Thanks. I would remove those useless branches but some may prefer to use them so whatever... > That's kind of trying to put the toothpaste back in the > tube... gitlab-runner is a golang project, that is going to just keep > happening, IMHO. :) So true. :) On that instance with upstream bug they've added a lot of useless garbage to "vendor" (e.g. examples, docs, etc.) that was not needed to satisfy any dependency. > I hope my small amount of work will have been useful for you! Did I miss any commits? > Maybe I should have opened a bug report instead, too? Whatever works for you. I already know about new upstream release so I hope to get to packaging it eventually... Thanks. -- Regards, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- All the papers that matter live off their advertisements, and the advertisers exercise an indirect censorship over news. -- George Orwell, Why I Write --- ZERO flu deaths reported during 2020-2021 season. Never in medical history has an annual disease completely disappeared to be replaced by another one with the exact same symptoms.
Attachment:
signature.asc
Description: This is a digitally signed message part.