Am Mi., 17. Jan. 2024 um 17:08 Uhr schrieb John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de>:

> > This is exactly what it's supposed to mean. Packages distributed by
> Debian are obviously required
> > to not be broken when they hit stable. Otherwise an update wouldn't be
> accepted to  be sent to stable.
>
> The package is not broken. It works as intended by the upstream
> developers. It does not say anywhere
> that AusweisApp is supposed to work on a non-Qt system.
>

This is just not how anything works. Besides the fact that after Gnome was
made because people didn't like Qt's licensing and after a while they both
added compatibility for each others software - there basically isn't such
thing as a "non-Qt system". A non-Qt system would be a system with no Qt
dependencies available. But you'll probably never find any distro where
this is the case. That's why any package will always work with any DE, no
matter if it was build with GTK, Qt or something else. Sure, with Wayland
needing to be supported by the DEs instead of a  generic server, it can
happen that some minor things need to be harmonized, e.g. communicating a
sensible cursor size to Qt apps in a Gnome DE, but that's it. There's
absolutely nothing that makes Qt apps Plasma only or GTK apps Gnome only.

>
> > And since neither Debian with KDE nor Debian with Gnome is a separate
> distribution, obviously a
> > package is supposed to work with both.
>
> Sorry, but that's just non-sense. If an upstream project does not support
> GNOME, it will not
> support GNOME on Debian either. Again, you are barking up the wrong tree
> here.
>

Again, not how anything works.

>
> > That's why all KDE packages will pull in all necessary dependencies
> required to run in Gnome (or
> > any other DE offered by Debian) and vice versa. If any package would be
> allowed in stable in a
> > theoretical future where it only supports Wayland and not X while not
> all available DEs would
> > be supporting Wayland would be very questionable. And that's just
> another version of this exact problem.
>
> It's simply not possible to support every possible use cases. You just
> have to accept that.
>
Obviously not. But every use case supported by Debian itself must be
supported by the packages. With DEs it's not like with CPU architectures
where you can simply choose not to compile a package for a specific
architecture. Besides the fact that even that's not relevant. Even
AusweisApp is being compiled for pretty much any architecture supported by
debian, simply because there's nothing preventing it. That's at least true
for anything in the main repo. The only exception I know of is Steam, but
that's only shipped in contrib (and used to be non-free). So yes, every use
case supported by Debian stable in the main repo must be supported by every
package in that branch. Everything else wouldn't make any sense after all.

The real software world is not perfect.
>
> > > The limitations around GNOME support are an upstream issue and not
> related to packaging which
> > > is what I am doing. Claiming that a particular issue that is not a
> serious bug must be fixed
> > > before the next release is something that I would call entitlement. If
> you have figured out
> > > how to fix this particular problem, you are free to send a patch to me
> or upstream. That's
> > > how it works with community-maintained software.
> >
> > It's obviously serious since it literally renders the software unusable
> for some users. If you
> > have a different opinion, you should really re-read the severity levels'
> definitions:
> > https://www.debian.org/Bugs/Developer#severities
> > important: a bug which has a major effect on the usability of a package,
> without rendering it
> > completely unusable to everyone.
> > This is literally what this is.
>
> And you're still missing the point that the issue you are seeing here is
> not a limitation of Debian
> but of the upstream software you are using. You are blaming me for
> something that I am not responsible
> for.
>
> I am neither the upstream developer of GNOME nor of Qt or the AusweisApp.
> I am the person who is
> maintaining AusweisApp in Debian. And I am shipping the software as it is
> provided by upstream.
>
> If upstream doesn't support usecase X, I am not the person to be blamed.
>
You really should look up how "Maintainer" was defined when the concept was
introduced: https://www.debian.org/vote/2007/vote_003
One of the points: unfixed bugs may lead to the Maintainers key removal
from the Debian Maintainers keyring, effectively revoking their status of
being a Maintainer.


> > > Neither me nor the upstream maintainer are actually getting paid to
> provide this application
> > > on Linux or on Debian, so it's perfectly fine that we get to decide
> how we spend our free
> > > time.
> >
> > Nobody said otherwise. But literally with a bug this severe v2 can't and
> shouldn't be accepted
> > into stable with Trixie. And if nobody fixes it, it's questionable how
> long this package will be
> > accepted to stay in the repos at all.
>
> Again, the package is working as intended by upstream and the issue you
> are seeing is a known
> limitation. Software is never perfect and has always known issues.
>
It's not. Please stop confusing the very basics.

>
> And instead of trying to educate people who do the actual work on how they
> are supposed to do
> the work, you could roll up your sleeves and try to help resolve this
> issue. Apparently, using
> AusweisApp on GNOME is very important to you. So I recommend you get start
> and help upstream,
> who has been CC'ed on this issue by me, fix the bug.
>
>
> Again, you should really read up on what it means to be a maintainer. If
you aren't up to the challenge, don't be one. Nobody forced you into this
position. You took it of free will - and at least you were supposed to know
what that means.

Reply via email to