Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Hi Joachim,
On Sat, Feb 24, 2024 at 06:37:02PM +0100, Joachim Zobel wrote:
> Hi.
>
> I'll reply to the DEP-14 issue while working on the others.
>
> Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost:
> > > https://github.com/volkszaehler/vzlogger.git ;
> > >
> > > on branch debian-0.8.3-1.
> >
> > (There is no such branch on that repo, but a "debian" one.)
>
> Sorry, forgot to merge that.
>
> > Please see dep14 (https://dep-team.pages.debian.net/deps/dep14/) for
> > recommendation how to layout the repository used for packaging, I'd
> > even recommend to use an extra repository for the packaging.
>
> I know about DEP-14 and actually tried it. I found it however very
> inconvenient to use and I think this is because it is inappropriate for
> the current situation.
Sorry, I don't get what you mean. Why is it inappropiate?
Putting DEP14 (branch names[1]) aside, Debian packagaing is supposed to
be "linear", you work on a package, upload it, and the next iteration
you base your work on the already uploaded version.
It makes no sense to have a branch for every Debian package revision,
because once it has been uploaded it will become immuteable, you cannot
reupload the same revesion, the upload will be rejected.
We *tag* Debian package releases to mark them, and when the next one is
ready, it will be based on the old revision, so it is more natural to
continue on that branch.
Also, you are supposed to note the branch in VCS-Git where packaging is
happening, and this is _a_ branch (that's singular!), see the Debian
Policy for extra reasoning.
[1] which are only getting important if you need to manage different
Debian release suites or backports on top. the scheme <vendor>/<suite>,
e.g debian/unstable is meant to aid here. note: you cannot have branches
"debian" _and_ "debian/$suite", because git won't allow that. If you use
"debian" as branch, this will make it harder to deploy DEP14 later.
> The package is maintained in the upstream repository as a native
> package (by me). This is necessary because Debian packages are built as
> part of the upstream releases. So all packaging changes happen upstream
> first.
If you are in control of upstream packaging, well, frankly, than you
are in control to do things propoerly upstream.
The first thing is: stop building native packages. Native packages are
the wrong approach 99% of the time. [2]
This will also save you a lot of time, you won't need to maintain two
flavours. (As Debian packages need to follow Debian rules and not
upstream rules, a native package will not be acceptable for Debian.)
The upstream guide discourages to have a debian/ directory in the
upstream main branch [3], but if you do, and base your packaging on
it.
Having a debian directory in "main" and another branch, especially if
they are divereged, will only confuse people. (and they might to need
to work on your package, e.g if there is a need for an NMU.)
So pick one.
[2] https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F
You should only use a native Debian package when it is clear that the
package would not be useful outside the context of a Debian system, and
would never be distributed except packaged for Debian or its
derivatives. Even if the software is currently only available in Debian,
if someone could reasonably use the software on another distribution or
on another operating system, then the package should be non-native
[3] https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source,
third paragraph.
> The changes that are later needed to turn an upstream native
> release into a Debian release are few and won't change much over time.
> So a patch makes sense IMHO.
As said, native is wrong anyways, but the packaging directory should be
orthogonal to the upstream version, as the upstream version needs also
to work on non-Debian systems, don't they?
> This situation can change when vzlogger reaches stable (and as a result
> reaches Raspbian). At that point maintaining a package in the upstream
> repo is no longer necessary.
This sounds wrong.
Either you package in an dedicated repository, or you don't. That is
orthogonal to whether the package is in Debian or not.
> For now I would prefer to use the suggested release workflow (which I
> am already using for libsml, where the situation is the same).
tracker.d.o is unhappy:
"The VCS repository is not up to date, push the missing commits."
Your process breaks tooling in Debian. It is broken.
> I am
> aware that the DEP-14 layout works well if upstream is not doing
> package maintenance and I am not generally against it.
It is not significant for DEP-14 whether upstream is doing package
maintaince or not. In your instance, you are in control of the upstream
repository, so you *can* change things. In situations where this is not
possible, we'd ignore the debian/ directory from upstream completly.
My other current
> ITP #1062335 is using it.
>
> https://salsa.debian.org/debian-iot-team/tasmota-device-manager
>
> Sincerely,
> Joachim
>
--
tobi
Reply to: