Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #100772 > unrolled thread

Steam Deck: good news for Linux gaming, bad news for Debian :(

Back to article view | Back to linux.debian.devel

Contents

  Steam Deck: good news for Linux gaming, bad news for Debian :( Samuel Henrique <samueloph@debian.org> - 2021-07-17 14:50 +0200
    Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Andrey Rahmatullin <wrar@debian.org> - 2021-07-17 16:00 +0200
    Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Luca Boccassi <bluca@debian.org> - 2021-07-17 17:20 +0200
      Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Sandro Tosi <morph@debian.org> - 2021-08-10 19:40 +0200
        Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Andrey Rahmatullin <wrar@debian.org> - 2021-08-10 19:40 +0200
          Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Paul Wise <pabs@debian.org> - 2021-08-11 03:00 +0200
            Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Calum McConnell <calumlikesapplepie@gmail.com> - 2021-08-11 07:10 +0200
              Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Marc Haber <mh+debian-devel@zugschlus.de> - 2021-08-11 08:50 +0200
                Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Steffen Möller <steffen_moeller@gmx.de> - 2021-08-11 11:40 +0200
                  Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Vincent Bernat <bernat@debian.org> - 2021-08-11 16:10 +0200
                    Re: Steam Deck: good news for Linux gaming, bad news for Debian :( "Theodore Ts'o" <tytso@mit.edu> - 2021-08-11 18:10 +0200
                      Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2021-08-12 05:30 +0200
                        Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Paul Wise <pabs@debian.org> - 2021-08-12 06:50 +0200
                          Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Jonathan Dowland <jmtd@debian.org> - 2021-08-14 08:50 +0200
                            Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Moritz Mühlenhoff <jmm@inutil.org> - 2021-08-14 09:20 +0200
                            Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Wouter Verhelst <wouter@debian.org> - 2021-08-16 16:30 +0200
                    Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Romain Porte <debian@microjoe.org> - 2021-08-12 16:40 +0200
                      Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Andreas Tille <andreas@an3as.eu> - 2021-08-12 23:10 +0200
                        Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Jonas Smedegaard <jonas@jones.dk> - 2021-08-13 00:00 +0200
                      git workflows (was: Steam Deck: good news for Linux gaming, bad  news for Debian :() Sean Whitton <spwhitton@spwhitton.name> - 2021-08-13 00:40 +0200
                        Re: git workflows (was: Steam Deck: good news for Linux gaming, bad  news for Debian :() Jonathan Dowland <jmtd@debian.org> - 2021-08-14 09:00 +0200
                          Re: git workflows (was: Steam Deck: good news for Linux gaming, bad  news for Debian :() Sean Whitton <spwhitton@spwhitton.name> - 2021-08-15 07:10 +0200
    Re: Steam Deck: good news for Linux gaming, bad news for Debian :( "Thaddeus H. Black" <thb@debian.org> - 2021-07-18 02:20 +0200
    Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Paul Wise <pabs@debian.org> - 2021-07-18 03:00 +0200
      Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Hanno 'Rince' Wagner <wagner@debian.org> - 2021-07-18 10:40 +0200
        Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Paul Wise <pabs@debian.org> - 2021-07-19 04:30 +0200
          Re: Steam Deck: good news for Linux gaming, bad news for Debian :( Simon McVittie <smcv@debian.org> - 2021-07-19 22:30 +0200
    Re: Steam Deck: good news for Linux gaming, bad news for Debian? Simon McVittie <smcv@debian.org> - 2021-07-19 23:40 +0200
      Re: Steam Deck: good news for Linux gaming, bad news for Debian? Samuel Henrique <samueloph@debian.org> - 2021-07-20 00:30 +0200

Page 1 of 2  [1] 2  Next page →

#100772 — Steam Deck: good news for Linux gaming, bad news for Debian :(

Hello d-devel,

As some of you already seem, we have very good news for the Linux
gaming community, although somewhat bad for Debian:
https://www.steamdeck.com

The Steam Deck is a portable gaming device, running SteamOS, to be
released later this year.
Review video from 2kliksphilip:
Valve Steam Deck - The Budget Gaming PC We Need
https://youtu.be/zBEpymHvrpo

The bad news for Debian comes from this page:
https://www.steamdeck.com/en/tech
Operating System: SteamOS 3.0 (Arch-based)

SteamOS used to be based on Debian, and Valve seems to have decided to
go with Arch instead (great news for Arch, don't get me wrong).

The reasons for the switch have not been publicized, but I think we're
safe to assume it's because Debian is not fit for the majority of the
desktop/gaming users, at least not officially (since testing is not a
supported release). I remember having some issues due to SteamOS being
based on stable. These are the people who need to be able to run the
most up-to-date packages, especially drivers and kernel (backports is
not always there).

Now, this is ok for regular users, as they can take the risk[0] of
running testing to get all the benefits from it, and that's what I
recommend to pretty much anyone running Debian on a desktop, though I
recognize some people prefer to run stable.

Debian Testing is very close to Arch wrt up-to-date packages (when not
frozen) but most people don't know this and we end up being known for
not supporting newer hardware/software[1].

This is a niche that is currently fulfilled by Fedora, Ubuntu non-LTS,
Arch... and Debian Testing (only one which is not an official
release).

I know the situation is not as simple as calling Debian Testing
something else and making it an official release, my intentions here
are to expose the current issue we have: that we don't fulfill the
needs of a lot of desktop users and SteamOS is now Arch-based, most
likely because of this.

So here's my wish that someday we can have a Debian semi-rolling
release (if we want to have it based on Testing), with security
support and a different name other than "Testing".

[0] No security team support.
[1] And software matters here because the gaming side of Linux still
receives major improvements with new releases of things like Proton.

Have a nice weekend!

-- 
Samuel Henrique <samueloph>

[toc] | [next] | [standalone]

#100773

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jul 17, 2021 at 01:48:32PM +0100, Samuel Henrique wrote:
> that we don't fulfill the needs of a lot of desktop users 
It is known, as we don't even provide an official installer ISO that makes
their hardware usable.

> So here's my wish that someday we can have a Debian semi-rolling
> release (if we want to have it based on Testing), with security
> support and a different name other than "Testing".
Obligatory https://wiki.debian.org/ReleaseProposals

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#100774

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2021-07-17 at 13:48 +0100, Samuel Henrique wrote:
> Hello d-devel,
> 
> As some of you already seem, we have very good news for the Linux
> gaming community, although somewhat bad for Debian:
> https://www.steamdeck.com
> 
> The Steam Deck is a portable gaming device, running SteamOS, to be
> released later this year.
> Review video from 2kliksphilip:
> Valve Steam Deck - The Budget Gaming PC We Need
> https://youtu.be/zBEpymHvrpo
> 
> The bad news for Debian comes from this page:
> https://www.steamdeck.com/en/tech
> Operating System: SteamOS 3.0 (Arch-based)
> 
> SteamOS used to be based on Debian, and Valve seems to have decided to
> go with Arch instead (great news for Arch, don't get me wrong).
> 
> The reasons for the switch have not been publicized, but I think we're
> safe to assume it's because Debian is not fit for the majority of the
> desktop/gaming users, at least not officially (since testing is not a
> supported release). I remember having some issues due to SteamOS being
> based on stable. These are the people who need to be able to run the
> most up-to-date packages, especially drivers and kernel (backports is
> not always there).
> 
> Now, this is ok for regular users, as they can take the risk[0] of
> running testing to get all the benefits from it, and that's what I
> recommend to pretty much anyone running Debian on a desktop, though I
> recognize some people prefer to run stable.
> 
> Debian Testing is very close to Arch wrt up-to-date packages (when not
> frozen) but most people don't know this and we end up being known for
> not supporting newer hardware/software[1].
> 
> This is a niche that is currently fulfilled by Fedora, Ubuntu non-LTS,
> Arch... and Debian Testing (only one which is not an official
> release).
> 
> I know the situation is not as simple as calling Debian Testing
> something else and making it an official release, my intentions here
> are to expose the current issue we have: that we don't fulfill the
> needs of a lot of desktop users and SteamOS is now Arch-based, most
> likely because of this.
> 
> So here's my wish that someday we can have a Debian semi-rolling
> release (if we want to have it based on Testing), with security
> support and a different name other than "Testing".
> 
> [0] No security team support.
> [1] And software matters here because the gaming side of Linux still
> receives major improvements with new releases of things like Proton.
> 
> Have a nice weekend!

I think it would be quite nice to hear from Valve or some of the Debian
folks who work(ed) with them, about the reasons for the rebase. With no
ill will, just to understand what the problems were and if we can learn
something from them.

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#100945

> I think it would be quite nice to hear from Valve or some of the Debian
> folks who work(ed) with them, about the reasons for the rebase. With no
> ill will, just to understand what the problems were and if we can learn
> something from them.

https://www.pcgamer.com/this-is-why-valve-is-switching-from-debian-to-arch-for-steam-decks-linux-os/

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [prev] | [next] | [standalone]

#100946

[Multipart message — attachments visible in raw view] — view raw

On Tue, Aug 10, 2021 at 01:31:12PM -0400, Sandro Tosi wrote:
> > I think it would be quite nice to hear from Valve or some of the Debian
> > folks who work(ed) with them, about the reasons for the rebase. With no
> > ill will, just to understand what the problems were and if we can learn
> > something from them.
> 
> https://www.pcgamer.com/this-is-why-valve-is-switching-from-debian-to-arch-for-steam-decks-linux-os/
TLDR:

At launch, the Steam Deck will undoubtedly need multiple small updates to
make sure everything works flawlessly. Some of which could affect the
underlying kernel—not something that Debian readily lends itself to.

That's something Valve designer, Lawrence Yang, told us during our
hands-on time with the Deck when we asked about the switch from Debian to
Arch.

"So, Arch Linux, one of the main reasons, there's a couple, but the main
reason is the rolling updates of Arch allows us to have more rapid
development for SteamOS 3.0," says Yang. "We were making a bunch of
updates and changes to specifically make sure that things work well for
Steam deck, and Arch just ended up being a better choice for them."

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#100948

On Tue, Aug 10, 2021 at 5:38 PM Andrey Rahmatullin wrote:

> "So, Arch Linux, one of the main reasons, there's a couple, but the main
> reason is the rolling updates of Arch allows us to have more rapid
> development for SteamOS 3.0," says Yang. "We were making a bunch of
> updates and changes to specifically make sure that things work well for
> Steam deck, and Arch just ended up being a better choice for them."

Sounds like Debian testing would have worked for them too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#100949

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2021-08-11 at 00:51 +0000, Paul Wise wrote:
> On Tue, Aug 10, 2021 at 5:38 PM Andrey Rahmatullin wrote:
> 
> > "So, Arch Linux, one of the main reasons, there's a couple, but the
> > main
> > reason is the rolling updates of Arch allows us to have more rapid
> > development for SteamOS 3.0," says Yang. "We were making a bunch of
> > updates and changes to specifically make sure that things work well
> > for
> > Steam deck, and Arch just ended up being a better choice for them."
> 
> Sounds like Debian testing would have worked for them too.

Except testing lacks direct security support, and spends about a quarter
of the time in a feature freeze.  It isn't a true rolling release: the
wheels are squares instead of circles.

[toc] | [prev] | [next] | [standalone]

#100950

On Wed, 11 Aug 2021 01:09:29 -0400, Calum McConnell
<calumlikesapplepie@gmail.com> wrote:
>On Wed, 2021-08-11 at 00:51 +0000, Paul Wise wrote:
>> On Tue, Aug 10, 2021 at 5:38 PM Andrey Rahmatullin wrote:
>> 
>> > "So, Arch Linux, one of the main reasons, there's a couple, but the
>> > main
>> > reason is the rolling updates of Arch allows us to have more rapid
>> > development for SteamOS 3.0," says Yang. "We were making a bunch of
>> > updates and changes to specifically make sure that things work well
>> > for
>> > Steam deck, and Arch just ended up being a better choice for them."
>> 
>> Sounds like Debian testing would have worked for them too.
>
>Except testing lacks direct security support, and spends about a quarter
>of the time in a feature freeze.  It isn't a true rolling release: the
>wheels are squares instead of circles.

I think that the experience that Debian has made with Stream is our
classic problem: We try to cater for all, and annoy the people who
want quicker releases. After we have driven away the users who want
quicker releases in the early 2000s (they have moved to Ubuntu or to
the rolling release distributions), we have taken a quicker pace,
driving away the users that want more stability (they have probably
moved to the Red Hat / CentOS world despite them having actually less
stability by defining stability and support time differently than we
do), and still we're too slow for downstream users like Steam.

This is either going to continue, or we finally commit to having more
than one release train, which of course comes with its own set of
issues, the biggest of them being volunteers and personpower.

There is no glory in supporting long support cycles.

Greetings
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#100952

On 11.08.21 08:46, Marc Haber wrote:
> On Wed, 11 Aug 2021 01:09:29 -0400, Calum McConnell
> <calumlikesapplepie@gmail.com> wrote:
>> On Wed, 2021-08-11 at 00:51 +0000, Paul Wise wrote:
>>> On Tue, Aug 10, 2021 at 5:38 PM Andrey Rahmatullin wrote:
>>>
>>>> "So, Arch Linux, one of the main reasons, there's a couple, but the
>>>> main
>>>> reason is the rolling updates of Arch allows us to have more rapid
>>>> development for SteamOS 3.0," says Yang. "We were making a bunch of
>>>> updates and changes to specifically make sure that things work well
>>>> for
>>>> Steam deck, and Arch just ended up being a better choice for them."
>>> Sounds like Debian testing would have worked for them too.
>> Except testing lacks direct security support, and spends about a quarter
>> of the time in a feature freeze.  It isn't a true rolling release: the
>> wheels are squares instead of circles.
> I think that the experience that Debian has made with Stream is our
> classic problem: We try to cater for all, and annoy the people who
> want quicker releases. After we have driven away the users who want
> quicker releases in the early 2000s (they have moved to Ubuntu or to
> the rolling release distributions), we have taken a quicker pace,
> driving away the users that want more stability (they have probably
> moved to the Red Hat / CentOS world despite them having actually less
> stability by defining stability and support time differently than we
> do), and still we're too slow for downstream users like Steam.
>
> This is either going to continue, or we finally commit to having more
> than one release train, which of course comes with its own set of
> issues, the biggest of them being volunteers and personpower.
>
> There is no glory in supporting long support cycles.

For steam, our competitor may be arch. For science projects, it is conda
(ok, hello, yes, you brew and guix people, you are also competitors) -
which rolling and (bonus feature) cross-platform - with CI and often it
is upstream preparing and using these packages themselves.

I have no exact idea what to change, though. A rolling Debian would be
cool, yes, but also a bit late when compared with environments that
Conda offers or the ease that comes with multiple installations of conda
to e.g. avoid name conflicts. If we had a chroot for which you do not
need to be root, then together with snapshot.d.o we would be darn close
to what Conda is offering. I have no idea how to get there, though. With
singularity maybe?

Best,
Steffen

[toc] | [prev] | [next] | [standalone]

#100959

 ❦ 11 August 2021 11:27 +02, Steffen Möller:

> I have no exact idea what to change, though. A rolling Debian would be
> cool, yes, but also a bit late when compared with environments that
> Conda offers or the ease that comes with multiple installations of conda
> to e.g. avoid name conflicts. If we had a chroot for which you do not
> need to be root, then together with snapshot.d.o we would be darn close
> to what Conda is offering. I have no idea how to get there, though. With
> singularity maybe?

We package only a very small subset of Conda, I don't see in what
universe we could be competitive, rolling or not rolling.

I think we have more systemic issues. I am quite impressed how Nix/NixOS
is able to pull so many packages and modules with so few people. But
they use only one workflow, one way to package, one init system, etc.
Looking at Arch, one workflow, one way to package, one init system, etc.
Looking at Fedora, one workflow, one way to package, one init system.
Let me take again the example with Nix. Anyone can do a simple pull
request and gets its change accepted. Each package has a maintainer, but
the ownership is quite weak. The maintainer may say no, but if they are
just busy, someone else may merge the change if it looks reasonable.

In Debian, we have many workflow (BTS, MR to submit changes, Git, not
Git, Git workflow 1, Git workflow 2, Git workflow 3), many ways to
package (just one makefile, old debhelper, new dh), many init systems.
And the ownership problem prevents people to help from time to time.
There are so many packages I come accross that could just be updated to
a more recent version and looks like semi-abandoned but I just don't try
any more because there are so many ways to fail.

I still trust Debian to be the most technically excellent distribution,
but that's not all it makes to stay relevant. My point is that it would
help to reduce the technical liberties we take in Debian. However, I
don't think that's who we are.

Today, it is very difficult to only use Debian own packages. We just
tell people "just add random repositories". Nix and Arch are able to
have almost everything packaged. Nix is able to include into a single
workflow most other language ecosystems.
-- 
The last thing one knows in constructing a work is what to put first.
		-- Blaise Pascal

[toc] | [prev] | [next] | [standalone]

#100960

On Wed, Aug 11, 2021 at 04:08:13PM +0200, Vincent Bernat wrote:
> I think we have more systemic issues. I am quite impressed how Nix/NixOS
> is able to pull so many packages and modules with so few people. But
> they use only one workflow, one way to package, one init system, etc.
> Looking at Arch, one workflow, one way to package, one init system, etc.
> Looking at Fedora, one workflow, one way to package, one init system.

I wouldn't call it "issues" per se.  It's all about trade-offs.
Having only one way to do things helps velocity, but it also impedes
flexibility, which some users and developers value.

Having a faster release cycle either requires a lot more engineering
resources (volunteers or paid, depending on the distro) and/or it
forces users to continually update to new major releases if they want
to continue getting security updates.

There still *are* enterprise customers who like the longer release
cycles.  Some of them even use Debian and have privately referred to
it as "their secret advantage".  Whether it is a large number or not,
and whether they are contributing back to the Debian community (and
whether that is important to us) are different questions.

Requiring that all packages use the common distro-shipped shared
libraries (or Perl or Python components) as opposed to shipping their
own is another engineering tradeoff where there may be some
advantages, but also disadvantages, in terms of effort, pain if the
shared libraries or Perl/Python components laugh at the concept of
"stable API's", and userspace package upstreams that want to work
across a large number of distributions all supporting different
versions of their dependencies, and/or upstream that want to move
faster than Debian is willing to release.

These are all tradeoffs, and there is no one right answer.  That may
be painful for those who believe that there is, and it is a hidden
assumption in the blithe assertion that Debian should be "The
Universal OS".  Unfortunately, these tradeoffs mean that there can
*be* no single "Universal OS".  There will always be a need for
different horses for different courses.

Debian has taken a strong opinionated stance on many of these
tradeoffs, and that's fine.  It's not necessarily a problem, except
insofar that some people want Debian to be applicable for a particular
use case, such as for example Steam OS.  It might be the answer is
that Debian simply can't be as Universal as we might aspire to be.

Cheers,

					- Ted

[toc] | [prev] | [next] | [standalone]

#100965

I am fine with Debian's release cycle but It would be nice to see more
packages. For example Debian is missing KDE's Amarok music manager. I
am happy to see Debian 11 gained KDE Elisa music manager. I am sad to
see that VirtualBox is not available on Debian 11. I had to jerry-rig
it using the Ubuntu Focal repo from Oracle.

OpenSUSE Tumbleweed is a good rolling distro, I am surprised Steam did
not use it. OpenSUSE was the repo Plasma Active shipped with. I tried
Tumbleweed but I got tired of the constant need to download all of the
packages. I am on a metered internet connection and a Rolling Distro
is just not for me.

Debian needs to have a mechanism like the openSUSE OBS Open Build
Service, where people can create Repo's of newer software versions to
use with stable Debian. On openSUSE I use the stable KDE Repo's to
keep KDE up-to-date with the latest stable releases.

Tim

[toc] | [prev] | [next] | [standalone]

#100968

On Thu, Aug 12, 2021 at 3:22 AM Timothy M Butterworth wrote:

> Debian is missing KDE's Amarok music manager.

Amarok was removed as it required the obsolete Qt 4 library. Now that
upstream has finally ported it to Qt5, it could be reintroduced to
Debian.

https://tracker.debian.org/pkg/amarok
https://tracker.debian.org/news/1055955/removed-290-2-from-unstable/
https://bugs.debian.org/935022
https://amarok.kde.org/en/node/890
https://www.debian.org/doc/manuals/developers-reference/ch05.html#reintroducing-pkgs

> VirtualBox is not available on Debian 11.

VirtualBox is not suitable for Debian stable because of how upstream
does security updates.

https://tracker.debian.org/pkg/virtualbox
https://bugs.debian.org/794466

Also, it isn't in main because it needs a non-free compiler to build the BIOS.

> I got tired of the constant need to download all of the packages.
> I am on a metered internet connection.

There are a couple of Debian initiatives that could help here:

https://debdelta.debian.net/
https://wiki.debian.org/Teams/Dpkg/Spec/DeltaDebs

> where people can create Repo's of newer software versions to
> use with stable Debian.

We have backports for that, and there is the bikesheds idea.

https://backports.debian.org/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#101017

On Thu, Aug 12, 2021 at 04:42:51AM +0000, Paul Wise wrote:
> On Thu, Aug 12, 2021 at 3:22 AM Timothy M Butterworth wrote:
> 
> > Debian is missing KDE's Amarok music manager.
> 
> Amarok was removed as it required the obsolete Qt 4 library. Now that
> upstream has finally ported it to Qt5, it could be reintroduced to
> Debian.

That's an interesting way of presenting the situation. Amarok was
removed because we aggressively removed Qt4, dropping packages that were
still using it, rather than dropping it once it was no longer in use,
which would be the more traditional approach.

> > where people can create Repo's of newer software versions to
> > use with stable Debian.
> 
> We have backports for that, and there is the bikesheds idea.
> 
> https://backports.debian.org/

Backports is not analogous to the concepts Timothy was presenting. It's
*one* repository, not a system where people (not just Debian maintainers)
can create repos.


-- 
Please do not CC me for listmail.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#101019

Jonathan Dowland <jmtd@debian.org> schrieb:
>> Amarok was removed as it required the obsolete Qt 4 library. Now that
>> upstream has finally ported it to Qt5, it could be reintroduced to
>> Debian.
>
> That's an interesting way of presenting the situation. Amarok was
> removed because we aggressively removed Qt4, dropping packages that were
> still using it, rather than dropping it once it was no longer in use,
> which would be the more traditional approach.

We didn't "aggressively remove" it; Qt4 was already a long time EOLed when
we started to prune reverse deps. The same process which also happens/
happened for many other outdated and security relavant libs, think OpenSSL 1.0.

Talk is cheap if you're not the one who has to deal with the consequences
(like backporting security fixes to an unsupported release)

Cheers,
        Moritz

[toc] | [prev] | [next] | [standalone]

#101059

On Sat, Aug 14, 2021 at 07:48:06AM +0100, Jonathan Dowland wrote:
> Backports is not analogous to the concepts Timothy was presenting. It's
> *one* repository, not a system where people (not just Debian maintainers)
> can create repos.

extrepo tries to help there, and now that bullseye is released, should
be more usable for everyone.

Unfortunately it requires you to do all the handywork in order to have
an actual, signed, repository, but reprepro is easy enough to use and
works well enough for most use cases; it's something that we could
document somewhere and then point people to it.

-- 
     w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

[toc] | [prev] | [next] | [standalone]

#100995

[Multipart message — attachments visible in raw view] — view raw

Hi,

11/08/2021 16:08, Vincent Bernat :
> I think we have more systemic issues. I am quite impressed how Nix/NixOS
> is able to pull so many packages and modules with so few people. But
> they use only one workflow, one way to package, one init system, etc.
> Looking at Arch, one workflow, one way to package, one init system, etc.
> Looking at Fedora, one workflow, one way to package, one init system.

I think this is a major point. I am a new Debian contributor after a
good time of ArchLinux PKGBUILD writing. I find Debian technically
superior on the packaging side, and would not trade it for PKGBUILD. But
there are so many ways to do things. After a lot of exploration, I have
found that the tooling that I was the most comfortable with was:

  * Salsa VCS
  * GBP for git + patching (+ DEP-conformant branch names)
  * dh

However there are so many other ways to do things. Some packages are not
on Salsa. Some packages use manually generated diff files. Different
branch names everywhere (debian/latest vs. debian/master vs.
debian/unstable vs. master…). I think progressive enforcing of a
workflow would help new maintainers to not be lost in the packaging jungle.

> I still trust Debian to be the most technically excellent distribution,
> but that's not all it makes to stay relevant. My point is that it would
> help to reduce the technical liberties we take in Debian. However, I
> don't think that's who we are.

Maintainers like their freedoms, but enforcing some tools at some point
could make it easier for everyone to contribute and not relearn the
packaging process for every package, because currently every package is
different. We are getting there by looking at the number of "3.0
(quilt)" packages and "dh" usage, but when a package does not conform to
this norm, it triggers a mental freeze on my side (and I want to migrate
it all to dh/3.0 quilt etc.).

> Let me take again the example with Nix. Anyone can do a simple pull
> request and gets its change accepted. Each package has a maintainer, but
> the ownership is quite weak. The maintainer may say no, but if they are
> just busy, someone else may merge the change if it looks reasonable.
Maybe the interface helps too. With a single repository, everyone can
see every pull request easily. For Debian you would have to monitor all
repositories/bugs for NMUs waiting.

> In Debian, we have many workflow (BTS, MR to submit changes, Git, not
> Git, Git workflow 1, Git workflow 2, Git workflow 3), many ways to
> package (just one makefile, old debhelper, new dh), many init systems.
> And the ownership problem prevents people to help from time to time.
> There are so many packages I come accross that could just be updated to
> a more recent version and looks like semi-abandoned but I just don't try
> any more because there are so many ways to fail.
To me the problem is not to do the technical migration, but to make it
acceptable to the current maintainer that will usually not want to
change their workflow — or not answer at all. One issue is that you
cannot repack everything and propose a NMU, because it is a major
change. So what do? Apart from RFS or co-maintaining, I do not know how
I can help "modernize" these packages. If I propose it as a .patch in a
bug and it is refused because the maintainers "does not like 3.0
(quilt)", I have lost a good chunk of time.
> Today, it is very difficult to only use Debian own packages. We just
> tell people "just add random repositories". Nix and Arch are able to
> have almost everything packaged. Nix is able to include into a single
> workflow most other language ecosystems.

We could have the same in Debian, but the constraints of "build from
source" and lack of interest for "contrib" and "non-free" channels is in
my opinion severely limiting the number of available packages. AUR
contains many packages that are not open-source nor built from source,
but users are happily using them when they want to.

For example for Spotify or VS Code (or many other external, sometimes
proprietary tools) you need to add an external repository. While on Arch
I guess you would use AUR. Why could not we use "contrib"/"non-free" for
the same purpose?

In the fonts team, it is increasingly complicated to build fonts from
source because they use so many javascript dependencies. I could propose
to ship the final .ttf/otf fonts into "contrib" instead. But given the
review duration for getting into "main", I guess "contrib" and
"non-free" are worse in terms of given attention.

Looking forward to pursue the discussion.

Best regards,

Romain.

[toc] | [prev] | [next] | [standalone]

#101003

Hi,

On Thu, Aug 12, 2021 at 02:06:37PM +0200, Romain Porte wrote:
> > Looking at Arch, one workflow, one way to package, one init system, etc.
> > Looking at Fedora, one workflow, one way to package, one init system.
> 
> I think this is a major point. I am a new Debian contributor after a
> good time of ArchLinux PKGBUILD writing. I find Debian technically
> superior on the packaging side, and would not trade it for PKGBUILD. But
> there are so many ways to do things. After a lot of exploration, I have
> found that the tooling that I was the most comfortable with was:
> 
>   * Salsa VCS
>   * GBP for git + patching (+ DEP-conformant branch names)
>   * dh
> 
> However there are so many other ways to do things. Some packages are not
> on Salsa. Some packages use manually generated diff files. Different
> branch names everywhere (debian/latest vs. debian/master vs.
> debian/unstable vs. master…). I think progressive enforcing of a
> workflow would help new maintainers to not be lost in the packaging jungle.

Amen.
 
> > I still trust Debian to be the most technically excellent distribution,
> > but that's not all it makes to stay relevant. My point is that it would
> > help to reduce the technical liberties we take in Debian. However, I
> > don't think that's who we are.
> 
> Maintainers like their freedoms, but enforcing some tools at some point
> could make it easier for everyone to contribute and not relearn the
> packaging process for every package, because currently every package is
> different. We are getting there by looking at the number of "3.0
> (quilt)" packages and "dh" usage, but when a package does not conform to
> this norm, it triggers a mental freeze on my side (and I want to migrate
> it all to dh/3.0 quilt etc.).

+1

May be we start defining workflow recommendations in policy or we draft
some development policy.  I'm aware that there are may be < 100 packages
inside the Debian package pool that are hard to push into some default
shape - but most packages with "unusual" workflows are that way for no
good reason.

Kind regards

     Andreas.

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#101004

[Multipart message — attachments visible in raw view] — view raw

Quoting Andreas Tille (2021-08-12 23:06:47)
> On Thu, Aug 12, 2021 at 02:06:37PM +0200, Romain Porte wrote:
> > Maintainers like their freedoms, but enforcing some tools at some 
> > point could make it easier for everyone to contribute and not 
> > relearn the packaging process for every package, because currently 
> > every package is different. We are getting there by looking at the 
> > number of "3.0 (quilt)" packages and "dh" usage, but when a package 
> > does not conform to this norm, it triggers a mental freeze on my 
> > side (and I want to migrate it all to dh/3.0 quilt etc.).
> 
> +1
> 
> May be we start defining workflow recommendations in policy or we 
> draft some development policy.  I'm aware that there are may be < 100 
> packages inside the Debian package pool that are hard to push into 
> some default shape - but most packages with "unusual" workflows are 
> that way for no good reason.

>From where do you get those estimates?

I think a good start would be to try identify which packages are 
maintained in which style and for which reasons.

I imagine that https://trends.debian.net/ can help to some extend but 
that's not enough to identify e.g. how many packages use cdbs due to 
being tied to Haskell, or how many packages of a certain "smell" have 
seen no recent maintainer update.

Just an idea for a concrete task that I think would help us understand 
what is holding back progress towards streamlining of packaging.  I am 
not volunteering to do the work myself, sorry: I have too much on my 
plate already.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#101005 — git workflows (was: Steam Deck: good news for Linux gaming, bad news for Debian :()

[Multipart message — attachments visible in raw view] — view raw

Hello Romain, others,

On Thu 12 Aug 2021 at 02:06PM +02, Romain Porte wrote:

> I think this is a major point. I am a new Debian contributor after a
> good time of ArchLinux PKGBUILD writing. I find Debian technically
> superior on the packaging side, and would not trade it for PKGBUILD. But
> there are so many ways to do things. After a lot of exploration, I have
> found that the tooling that I was the most comfortable with was:
>
>   * Salsa VCS
>   * GBP for git + patching (+ DEP-conformant branch names)
>   * dh
>
> However there are so many other ways to do things. Some packages are not
> on Salsa. Some packages use manually generated diff files. Different
> branch names everywhere (debian/latest vs. debian/master vs.
> debian/unstable vs. master…). I think progressive enforcing of a
> workflow would help new maintainers to not be lost in the packaging jungle.
>
>> I still trust Debian to be the most technically excellent distribution,
>> but that's not all it makes to stay relevant. My point is that it would
>> help to reduce the technical liberties we take in Debian. However, I
>> don't think that's who we are.
>
> Maintainers like their freedoms, but enforcing some tools at some point
> could make it easier for everyone to contribute and not relearn the
> packaging process for every package, because currently every package is
> different. We are getting there by looking at the number of "3.0
> (quilt)" packages and "dh" usage, but when a package does not conform to
> this norm, it triggers a mental freeze on my side (and I want to migrate
> it all to dh/3.0 quilt etc.).

I understand your frustration and I appreciate you persevering with
involvement in Debian -- thank you!  I'd like to offer a brief
counterpoint to some of what you say, however.

In many cases, indeed, the reasons why things like dh are not in use is
simply that no-one has taken the time to update the package yet, as you
say.  However, in other cases it is because the maintainer has thought
through the options and decided against using those particular tools and
workflows for principled reasons.

For example, there are those of us who think that the downsides of the
combination of 3.0 (quilt) and patches stored unapplied in git are
significant, and so we have made attempts to provide alternatives, such
as git-debrebase.  Contributing to Debian would be a lot less fun if we
were asked to just set these reasons aside and use something which to us
is clearly technically inferior.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.devel

csiph-web