Op 2025-12-31 17:38, schreef Pieter Lenaerts:
Hi Wouter, thanks for shedding light on the history. And thanks for
discussing this openly!
Assuming there are no additional aspects to the discussion I would
summarize pros and cons of adding eid-mw as a package to Debian as
follows:
Pro:
+ A. One less repository to add. Two sides to this: effort for the
sysadmin,
The effort is indeed not zero, but should still be minimal: we provide a
package that configures the repository for you, but you can also just
'extrepo enable belgium_eid'.
but also https://wiki.debian.org/DontBreakDebian.
This argument boils down to whether you believe I, a Debian Developer
who's been active in the project for almost 25 years now, will do things
in my private repository that might break your Debian.
+ B. The package would be part of the Debian release cycles. The Debian
team would prepare and test distribution releases in advance and the
distribution release itself would be part of the Debian release
process.
We do indeed lose that property. For what is essentially a niche
library, I question whether the value here is as large as you claim. I
mean, let's be honest; there's only a handful of people who would use it
in unstable or testing, so the ability to test issues before release is
somewhat limited.
+ C. The package would b reusable for more distros than today.
To some extent, yes. However the fact that we are going to have to do
different things in Ubuntu once the snap PKCS11 support is actually
documented might make it more complicated and confusing though if there
is a package in Ubuntu that won't work as expected.
Con:
- D. Upstream won't support issues. Not sure if this is really the
case. I may be making this assumption wrongly? And even so, determining
whether an issue is an upstream or a packager issue should not be too
big a concern.
I think you may be misunderstanding here what I wrote in my previous
mail about this.
Upstream will support, in the standard FLOSS way (i.e., we'll look at
issues and/or patches, will fix issues that we can reproduce, and might
merge patches if they have merit and don't break our own packages), any
third party packages and the people who make them.
The BOSA service desk (i.e. the people you can reach behind the contact
form on the official website) will not guarantee support for users who
are using third party packages, and will instead redirect such users to
the packager in question.
Additionally, it is occasionally required to update the eID middleware
because of a changing legal or technical environment. Laws about digital
identities sometimes change, which may require an update of the
software. So may details about the technical implementation, or
specifications for a new generation of cards that may require updates to
continue to handle the cards correctly. While it's rare that newer cards
are not backwards compatible, there have been *at least* two instances
since the card was introduced where cards were not backwards compatible
(once with the move to applet 1.7 and 2K RSA keys, once with the move to
applet 1.8 and ECDSA keys). Having a third party repository that always
has the most up to date version of the software makes this become a non
issue.
- E. Additional effort from one or more Debian package maintainers.
Well yes ;-)
+/- F. Debian is moving slowly to update urgent upstream package
releases. I'm not putting this in pro nor in the con category:
F.1 In general, new releases are I believe not very urgent. F2. I
think with backports there is a solution for moving too slowly. On the
one hand F3. adding bpo takes additional effort from the sysadmin, but
on the other hand F4. I feel a lot more comfortable adding bpo than
adding a third party repo.
I think that subjective feeling is perhaps not warranted.
Yes, we could use backports, but then there's more process involved, and
we'd have to teach users to always enable it. That sounds like a bad
idea to me.
Yes, we could also try to do stable updates, but I'm not sure the stable
release managers would feel it's warranted, especially not if there's
only backwards compatible spec changes. I'd have to check with them
though.
Do you see other aspects? If this is it I'm still inclined to package
at Debian...
Should we bring this bug to the attention of specific other people?
Pieter
