There's now a Debian User Repository in the style of the Arch User Repository

Quoting: sigmichMain reason I don't use Debian a while are outdated Nvidia drivers because I need stable branch for some specific software. Could DUR be used also for installing graphic drivers?

Backports has the latest stable drivers.

Personally, I prefer the Debian project's high-quality process and their repositories along with Flatpak+Flathub for certain key apps for which the most-recent stable release is needed for a particular use case.

The AUR is a great feature but mainly because the maintainers do such a good job curating content & keeping it up to date and fresh.

The philosophy behind Arch is also part of what makes the AUR great -- Keep It Simple Stupid.

I don't mind Debian stealing a page from Arch's book but I would really be encouraged to see everyone steal a page from Gentoo's book and essentially be able to install packages by compiling them from source with custom patches or installing bins.

Quoting: ElectricPrismThe AUR is a great feature but mainly because the maintainers do such a good job curating content & keeping it up to date and fresh.

The philosophy behind Arch is also part of what makes the AUR great -- Keep It Simple Stupid.

I don't mind Debian stealing a page from Arch's book but I would really be encouraged to see everyone steal a page from Gentoo's book and essentially be able to install packages by compiling them from source with custom patches or installing bins.

I mean isn't that basically what AUR does? It just simplifies that with PKGBUILDs, but the PKGBUILDs pretty much do the 'git clone', patch, make, etc. Or if it's officially part of ARCH, it's a bin.

As far as releases go, ARCH has always seemed more stable to me than Gentoo.

Quoting: slaapliedje

Quoting: sigmichMain reason I don't use Debian a while are outdated Nvidia drivers because I need stable branch for some specific software. Could DUR be used also for installing graphic drivers?

Backports has the latest stable drivers.

That's what I wanted to recommend as well. If you need to, you can even use the Nvidia driver from experimental (fear though not!). The driver seems to be so separated from the rest, this never gave me headaches either. But backports should be optimal.

For desktop usage this sounds great on paper, until you realize that Debian as a rule tends to have very stale libraries, which means that DUR apps will eventually need to also fetch and install newer versions of these libraries from the DUR, which means that you'll keep on piling extra libraries on top of your Debian system apps and libs, especially if you like to have the newest versions of all the apps you frequently use and not just a few of them, which means that at this point you really shouldn't be using Debian but a distro more suited to desktop usage with up-to-date apps included from the get-go.

For server usage this sounds even greater on paper (a rock-solid system coupled with a few hand-selected up-to-date software/services? yay!) until you remember that this is a problem that has already been solved since a few years ago by Docker et al. Why have a DUR app messing with my rock-solid Debian system, when I can have a properly sandboxed container that does not pollute whatsoever the rest of my system?

TL;DR the DUR sounds great in theory but IMHO is actually not that great in practice. Maybe if it came a few years earlier it could have seized the day on the server in place of containers, but as it is now it seems more like a solution without a problem.

Dislaimer: I'm an Arch user who otherwise loves the AUR and its broad possibilities for a desktop distro (was one of the three main reasons I eventually ended up on Arch for the long-term, the other two being its rolling nature and its minimalism that allowed me to tailor my system exactly as I want it) and I'm even maintaining a few AUR packages myself. Though to be honest, the onset of Flatpak seems to be slowly spelling the end of the AUR as well. Not yet, but I'd say give it 5 years and people on other distros will be able to do with Flatpaks what Arch has been doing with the AUR since forever, only better than the AUR.

By the way :
- The author uses Ubuntu and has probably never made a classic Debian package even "unofficial".
- It doesn't really support Debian, but Ubuntu and the author consider it "the same" (watch out for names and versions of dependencies which may not be the same between Debian and Ubuntu).
- It uses PKGBUILD with an equivalent of makepkg for Debian named makedeb.
- It doesn't work with apt, it requires separate tools.
- The packages are compiled on the user's machine, this requires installing the build dependencies, the author probably does not know pbuilder / cowbuilder.
- It hardly supports any functionality of debhelper (like service management, debconf, running unit tests, etc.).
- The author used the Debian name without permission, "Debian User Repository" will probably be renamed shortly.

Quoting: Nibelheim- It doesn't really support Debian, but Ubuntu and the author consider it "the same" (watch out for names and versions of dependencies which may not be the same between Debian and Ubuntu).

Even Debian has 3 different versions (4 with oldstable) with different versions of libraries. I wonder how these PKGBUILDs will manage this?
(Arch has 2 versions + Manjaro, but they differ very little)

Quoting: axredneck

Quoting: Nibelheim- It doesn't really support Debian, but Ubuntu and the author consider it "the same" (watch out for names and versions of dependencies which may not be the same between Debian and Ubuntu).

Even Debian has 3 different versions (4 with oldstable) with different versions of libraries. I wonder how these PKGBUILDs will manage this?
(Arch has 2 versions + Manjaro, but they differ very little)

This is why I stick with backports (if I really want something stable) or just run testing.

I've ran Debian for decades at this point (even the same install on some systems and have just upgraded to the next stable release when it is ready). For desktop systems I just run testing, which the only time it gets semi-old is when they do a freeze in preparation for making the switch to it being the stable branch. This can last from 1 to 6 months sometimes, but when you look at the grander scale of things, that's not like it's ancient (libraries generally don't drop compatibility that often). Testing is basically Debian's rolling release.

Kind of sad that he just slapped the Debian name on there and considered them compatible. Ubuntu is a fork off of Debian Sid done every 6 months... Debian stable (if that is what he's targeting) has the potential of having 2 year old or more stuff in it.. Also one of the things that make PKGBUILDs easy to implement in Arch is that they don't differentiate -dev packages, and include the source with the binary.

Quoting: axredneck

Quoting: Nibelheim- It doesn't really support Debian, but Ubuntu and the author consider it "the same" (watch out for names and versions of dependencies which may not be the same between Debian and Ubuntu).

Even Debian has 3 different versions (4 with oldstable) with different versions of libraries. I wonder how these PKGBUILDs will manage this?
(Arch has 2 versions + Manjaro, but they differ very little)

Arch has 1 version since 2017, i686 support stoped. And before, the only difference was just 64 bits libs wasn't accessible to 32 bits Arch. Otherwise, everything was same (packages name etc...)

Manjaro is not Arch. Manjaro use his own repositories. Like Ubuntu is not Debian.

AUR has no Manjaro support. If something is not working on Manjaro, never ask about a fix to an AUR packager...

Quoting: Nibelheim

Quoting: axredneck

Quoting: Nibelheim- It doesn't really support Debian, but Ubuntu and the author consider it "the same" (watch out for names and versions of dependencies which may not be the same between Debian and Ubuntu).

Even Debian has 3 different versions (4 with oldstable) with different versions of libraries. I wonder how these PKGBUILDs will manage this?
(Arch has 2 versions + Manjaro, but they differ very little)

Arch has 1 version since 2017, i686 support stoped. And before, the only difference was just 64 bits libs wasn't accessible to 32 bits Arch. Otherwise, everything was same (packages name etc...)

Manjaro is not Arch. Manjaro use his own repositories. Like Ubuntu is not Debian.

AUR has no Manjaro support. If something is not working on Manjaro, never ask about a fix to an AUR packager...

I meaned 2 versions: stable and testing.

Quoting: Nibelheim

Quoting: axredneck

Quoting: Nibelheim- It doesn't really support Debian, but Ubuntu and the author consider it "the same" (watch out for names and versions of dependencies which may not be the same between Debian and Ubuntu).

Even Debian has 3 different versions (4 with oldstable) with different versions of libraries. I wonder how these PKGBUILDs will manage this?
(Arch has 2 versions + Manjaro, but they differ very little)

Arch has 1 version since 2017, i686 support stoped. And before, the only difference was just 64 bits libs wasn't accessible to 32 bits Arch. Otherwise, everything was same (packages name etc...)

Manjaro is not Arch. Manjaro use his own repositories. Like Ubuntu is not Debian.

AUR has no Manjaro support. If something is not working on Manjaro, never ask about a fix to an AUR packager...

I thought Arch supported ARM now?

Quoting: slaapliedje

Quoting: Nibelheim

Quoting: axredneck

Quoting: Nibelheim- It doesn't really support Debian, but Ubuntu and the author consider it "the same" (watch out for names and versions of dependencies which may not be the same between Debian and Ubuntu).

Even Debian has 3 different versions (4 with oldstable) with different versions of libraries. I wonder how these PKGBUILDs will manage this?
(Arch has 2 versions + Manjaro, but they differ very little)

Arch has 1 version since 2017, i686 support stoped. And before, the only difference was just 64 bits libs wasn't accessible to 32 bits Arch. Otherwise, everything was same (packages name etc...)

Manjaro is not Arch. Manjaro use his own repositories. Like Ubuntu is not Debian.

AUR has no Manjaro support. If something is not working on Manjaro, never ask about a fix to an AUR packager...

I thought Arch supported ARM now?

ArchARM exist but it's an independant project. You can't find any information about ArchARM on main arch website.

It's another distro based on Arch, maintained partially by the main Arch team.

And yes AUR packages usually works on ArchARM (I use it on PinePhone) but sometimes packages are x86_64 compatible only.

Quoting: Nibelheim

Quoting: slaapliedje

Quoting: Nibelheim

Quoting: axredneck

Quoting: Nibelheim- It doesn't really support Debian, but Ubuntu and the author consider it "the same" (watch out for names and versions of dependencies which may not be the same between Debian and Ubuntu).

Even Debian has 3 different versions (4 with oldstable) with different versions of libraries. I wonder how these PKGBUILDs will manage this?
(Arch has 2 versions + Manjaro, but they differ very little)

Arch has 1 version since 2017, i686 support stoped. And before, the only difference was just 64 bits libs wasn't accessible to 32 bits Arch. Otherwise, everything was same (packages name etc...)

Manjaro is not Arch. Manjaro use his own repositories. Like Ubuntu is not Debian.

AUR has no Manjaro support. If something is not working on Manjaro, never ask about a fix to an AUR packager...

I thought Arch supported ARM now?

ArchARM exist but it's an independant project. You can't find any information about ArchARM on main arch website.

It's another distro based on Arch, maintained partially by the main Arch team.

And yes AUR packages usually works on ArchARM (I use it on PinePhone) but sometimes packages are x86_64 compatible only.

Somethings are simply written to only work on x86 or x86_64. Which is why most will end up having to rebuy their software for their Macs when they upgrade to arm ones.

I think it's great. People can do as much or little of their own security reviews. Without the AUR or DUR, you can still go to Github or GitLab or Docker and run like anything. It's very different than picking a release branch because you can literally install one thing from the AUR or DUR, so it's not like you're committing to running a system made of experimental bubblegum.