11 ms·

DUR: The Debian User Repository

86 points by luke2m 5y ago

bscphil 5y ago
I'm excited to see someone is working on this. I have considered switching from Arch to Sid in the past, mainly so that I could run the same OS on all computers and because I like the DFSG. Two things have stopped me: * It's so much harder to build your own software packages on Debian. Even patching an existing Debian package can be painful, and having to write your own packages is even worse. I'm sure a dedicated enough user can learn to use the Debian packaging software proficiently, but it's a huge barrier to entry when I have something as easy as Arch's PKGBUILD syntax at my disposal. It looks like this project is interested in solving this problem: rather than using Debian's packaging tools for the DUR, it actually appears to literally be using makepkg with a Debian conversion script running on top. [1] * The systemd integration is currently quite bad. It's probably the source of a bunch of user complaints about systemd. Debian's systemd install currently still supports [2] and uses init scripts and update-rc.d, the very thing unit files were supposed to take us beyond. In fact, a pretty minimal Debian installation I have on a server has 14 init scripts, while my Arch install doesn't even have an /etc/init.d directory! On the whole, Debian administration is a lot more complicated than on Arch because of the relative complexity of the architecture. [1] https://docs.hunterwittenborn.com/makedeb/makedeb/intro https://docs.hunterwittenborn.com/makedeb/makedeb/intro [2] https://wiki.debian.org/Teams/pkg-systemd/Integration https://wiki.debian.org/Teams/pkg-systemd/Integration
- spinax 5y ago
  I agree, RPM is similarly just as easy amongst others who all sort of stick to a single control file design. This exact DEB ergonomic pain of files all over the place keeps me at arms length, it's clunky (to me) and the build process weirds me out with how many variations on tools used to get the same result. It's backwards compatible as all get go, I'll give you that.
- zxzax 5y ago
  >It's so much harder to build your own software packages on Debian. Even patching an existing Debian package can be painful, and having to write your own packages is even worse. I can't say that's been my experience, once I figured out dh_make [0] that made it pretty easy by handling most of the boilerplate. Building an existing package is as simple as doing `apt source` and then `dpkg-buildpackage` to rebuild it (you may have to do `apt build-dep` first too). I agree with the rest of your comments though. Edit: I haven't looked into the details of how it works but I would imagine that YMMV with trying to use makepkg that way. The hard part here isn't getting the packages to build, it's in reconciling the library dependencies across all the tens of thousands of packages that make up both distros. [0]: https://blog.packagecloud.io/eng/2015/07/14/using-dh-make-to-prepare-debian-packages/ https://blog.packagecloud.io/eng/2015/07/14/using-dh-make-to...
  - bscphil 5y ago
    Yeah, I'm vaguely aware of various wrappers that try to make the process easier, I should probably give those a try. Building an existing package is certainly very easy, but I've had problems trying to download the source, apply a patch, and then rebuild it. In Arch this is just "makepkg -o" then "makepkg -e" after you patch the source.
    - zxzax 5y ago
      Really? For me it's literally just `dpkg-buildpackage` after patching the source. I never had any problems with it.
      - corndoge 5y ago
        What package and how complex is it?
        zxzax 5y ago
        I'm not sure I understand the question? This is for any package. Of course you will run into trouble if you introduce breakage, like removing files that the build script expects to be there, or causing merge conflicts with patches applied by the build script. But those breakages can happen with any package manifest, including PKGBUILD.
        namibj 5y ago
        makepkg -o already applies patches. And makepkg -e after it is like calling it normally, if you don't touch anything in-between.
        zxzax 5y ago
        The difference there is that debhelper will usually try to keep its own modifications temporary, and otherwise keep the source in the same state as the original upstream source. So that way you know when there is going to be a merge conflict.
- thayne 5y ago
  > The systemd integration is currently quite bad. It's probably the source of a bunch of user complaints about systemd. I haven't used plain Debian, but this has been my experience with Ubuntu. Almost all the problems I've run into with systemd have been because of an interaction with init.d scripts that should be systemd units, or similar. My biggest complaint is that while systemd-resolved is supposed to be optional, on Ubuntu it is practically impossible to fully disable without breaking things, and disabling is officially "unsupported". On archlinux, if you want to use dnsmasq instead it is just a matter of disabling one service and enabling the other.
  - mst 5y ago
    This is actually something that keeps tempting me to try arch, since it having gone all-in on systemd early on would hopefully give me a more 'native' systemd experience and help me figure out which of my gripes are with systemd and which of them are with how-$distro-added-systemd. Thing is, I'd only want such an install for playing around with occasionally and as the argument upthread makes pretty clear, "doing a bulk upgrade occasionally" is something that really isn't regarded as a sensible way to run arch.
    - bscphil 5y ago
      I do my upgrades every few weeks, for what it's worth, and I've had the same Arch install since 2013. The size of the upgrade should very rarely have any effect on whether it succeeds; you're just more likely to have missed some major changes if you're upgrading without checking the latest news from the website. Partial updates are also unsupported, and in my experience that's the most common way people break things.
- throwawaaarrgh 5y ago
  > On the whole, Debian administration is a lot more complicated than on Arch because of the relative complexity of the architecture. This should be expected though. Debian has been around a lot longer and is depended on by more of the Linux world. Complexity is a natural outcome of more stakeholder requirements (more stakeholders = more requirements = more complexity). I won't get into the systemd holy war, but suffice to say that comparing the architecture of init scripts vs systemd is like comparing the design of a bicycle to a car. One most definitely is more complex than the other, but whether that's a good thing or not depends on what you want to do with it.
  - kijin 5y ago
    It's okay to ride a bicycle instead of a car, or vice versa. It's not okay to put bicycle tires on a car, or a car transmission on a bicycle. I have no complaints about distros that are either 100% systemd or 100% init scripts. The problem with Debian (and its derivatives) is that they're trying to maintain both at the same time. If they really want to support both "/etc/init.d/servicename start" and "systemctl start servicename" commands, one should be turned into an empty shell that simply invokes the other, like what Red Hat did with the "service" command. The current system kinda works out of the box, but goes out of sync as soon as you try to customize either the init script or the unit file.
    - andrewshadura 5y ago
      In fact, init scripts are only used by systemd when there are no corresponding native unit files.
      - kijin 5y ago
        A lot of debian packages supply both systemd unit files and init scripts. You can use either to step on the other's foot.
        andrewshadura 5y ago
        As I said, init scripts are only used if there's no unit file. If there's a systemd unit, the init script is ignored.
- mjw1007 5y ago
  The inconvenience goes further than building in the first place. If I want to try running a Debian package with an experimental patch as a one-off, I haven't found it too hard to build my own version. But AFAIK there's nothing that helps me manage the necessary work to rebuild with the same patch when a new distribution version comes along. Do source-based distributions have a good solution for this?
  - andrewshadura 5y ago
    If you use Git, you just run git merge. If not, uupdate gives a good enough result for further fine tuning.
- nextlevelwizard 5y ago
  This is off-topic, but the reason why I stay away from Arch is that it has not once, but twice, just fucked itself from right under me. First time around I was just getting up and running and as I installed python3 there was some mismatch between some very core libraries and I couldn't roll back since the library in question wasn't available anywhere, but python3 package (or something that came along with it) was linked against the old one. Only "work around" I found was to symlink the current lib to the old's path. Second time I just just running bog standard fetch & update. Then I rebooted as is normal after you update and it no longer booted. Arch is fine hobbyist distro and you for sure have to live on he edge, but I wouldn't use it for anything you expect to be able to use every day at a moments notice.
  - spinax 5y ago
    > Arch is fine hobbyist distro and you for sure have to live on he edge, but I wouldn't use it for anything you expect to be able to use every day at a moments notice. I disagree 100%. This laptop I'm typing from now was installed 2014-07-06, it's my main personal machine with all the random things your typical desktop does and it works great. I similarly used a work laptop almost as long until I was forced off Arch for compliance reasons this year (sigh). Your anecdotal failures are not everyone's experience, definitely not mine.
    - hjek 5y ago
      > This laptop I'm typing from now was installed 2014-07-06, It goes beyond anecdotal evidence. I mean, if you look at the Arch news feed[0], there are a good few updates since then that are labelled "requires manual intervention". I like Arch and it's great they're posting those notices, but I don't think it can be claimed that upgrading an on-the-edge system is always problem free. [0] https://archlinux.org/news/ https://archlinux.org/news/
      - spinax 5y ago
        This is part of the agreement for using Arch, it's not a system you can ignore, you must actually pay attention to these news items. The upgrade tool I use actually shows new news to you front and center when performing an upgrade so you're blatantly aware that you have to follow instructions. Those are not "problems", they are "following instructions to keep up with changes." If you wand a distro to just ignore and hope it all goes well, Arch is not for you. Never was.
brainless 5y ago
Nice effort, the Arch User Repository is one of the benefits of the Arch way I feel. I have become so used to simply search "arch aur <VS Code>" or whatever I am looking for, finding it there, git clone and install. I keep installing random userspace software and I do not think AUR let me down. On a side note, I keep thinking there are so many great ideas spread over the many Linux distributions and not having a single joint effort makes it hard from an adoption point. I love having choice but I would really like more users to be able to use a (any) distribution.
- da_big_ghey 5y ago
  If you are think search and git clone are nice, waiting until you find out of AUR helper! `paru -Syu visual-studio-code-bin`
  - doubleunplussed 5y ago
    It's almost certainly a conscious choice to not use an AUR helper
    - brainless 5y ago
      I agree it is a conscious choice, I read it from the Arch Wiki, but to be honest I do not know why this can not be solved and accepted as a way forward.
- christophilus 5y ago
  I’ve only just started running Arch. One thing I don’t understand is the AUR security model. Aren’t you running arbitrary code / binaries built by some stranger on the interwebs on your machine? This is my biggest hesitation, and why I haven’t used AUR.
  - spinax 5y ago
    Using the 80/20 rule, most AUR packages are simply the build script ("PKGBUILD") instructions and perhaps a patch if required, etc. (or say adding a missing .desktop file). The process involves your AUR tool (I use "pikaur") downloading them, then executing the build instructions _locally_ on your device. So your desktop is actually the one downloading the real source code and compiling it, then installing it. The 20% side of this is yes, there are some prebuilt binaries in AUR - usually because (a) they are vendor proprietary code with no source (Zoom, for example) or (b) so insane to build that the vendor does it and you use their binaries (Firefox for example - it's a monster to compile). Most of the time these packages are clearly labeled, usually with "-bin" in the name so you can easily avoid them. You are executing build instructions written by someone else, but the tools encourage you to actually review them (and pikaur for example can show them to you for review right then and there). There is a level of trust involved and yeah, bad actors do try and slip in ugly things but they're usually found pretty quickly because folks are actually reviewing-before-installing as encouraged. It's risk management on this one, you take some personal responsibility for using AUR to pay attention.
akdor1154 5y ago
Took a while to work out what this was - nice intro at https://docs.hunterwittenborn.com/makedeb/debian-user-repository/intro https://docs.hunterwittenborn.com/makedeb/debian-user-reposi....
AussieWog93 5y ago
Linux does not need more package managers. It creates nothing but support burdens and busywork for developers (yes, user repositories too). I don't understand what people expect to achieve by further fragmenting a minority OS that makes up only 3% of Desktop users.
- brainless 5y ago
  - Market share is not the most important metric, resilience matters and Linux distributions have only gained in acceptance over years - People have a fear or even aversion toward experiments since it needs effort, but some folks are simply geeks - they will keep trying and more power to them - Some of these experiments, historically, have brought some of the best open innovations in the industry and moved even closed-source rooted companies to change mindset - Fragmentation is a marketing problem IMHO and I would like to see some ground between that and a consolidated Linux distro but it will not happen easily and that is OK - The enthusiasts like us do not need every other mainstream user on Linux but I am sure we would love that (I am a Linux user for 18 years) - This community is happy learning and trying new things, it is joyful So, more power to experimentors. The value of this community is in choice in a market that is dominated by the Apples and Microsofts who do not care about choice.
  - AussieWog93 5y ago
    I do get where you're coming from; this project just highlighted some personal frustrations I have with Desktop Linux is. I really wish we could have an open-source OS that was reliable and user-friendly for consumers (especially given how user-hostile Windows has become in the last 5 years), while similarly being non-burdensome for devs to deploy software to (which, to be fair, has improved a lot recently thanks to AppImageKit et al).
- TheFreim 5y ago
  Linux does need more package managers. Why? Because I like trying out new package managers and they don't harm people since they're not required to try or use them.
symlinkk 5y ago
Snap and Flatpak made distro specific user repositories like this obsolete
- akvadrako 5y ago
  Only for apps. They aren't really suited for libraries or even command line tools.
  - forgotpwd16 5y ago
    Not suited but possible. Snap allows packaging both libraries (e.g. GNOME runtime libraries) and command line tools (e.g. htop). Although those will live under /snap rather on common Unix paths (/usr/lib and /usr/bin), it just means those will work across distros rather on a specific one.
usr1106 5y ago
Can anybody explain me what is the purpose of the element-desktop-bin package? It just takes the binary from the packages.riot.im repo. That's what I do, too, by having packages.riot.im in my sources.list.d. Why repackage it?
- encryptluks2 5y ago
  I can't say for sure, but my take is that this repo is designed to use Arch-style PKGBUILD packaging. So, it appears to simply be an alternative package that uses the Arch-style packaging.
tapia 5y ago
I think this is great. I am an arch user at home, but at work I use Ubuntu. It is really difficult sometimes to get the latest version of a software installed in an easy way. I tend to use a lot of custom Makefiles for this, but I don't really like to not use the package manager. Being an arch user, I always wished it was as easy to build deb packages as it is to build packages with makepkg. I tried the debian way, and could successfully build some packages, but it is not at easy at using PKGBUILD files and I have to eventually. Now it seems to be possible to do this in Ubuntu! I will definitely try this!
- e3bc54b2 5y ago
  These days I just use Nix/Guix on work machines and get to using latest versions in less than 5 minutes. At home I've switched fully to NixOS.
aorth 5y ago
Interesting and cool idea. In my experience Arch Linux PKGBUILDs are easier and more straightforward to write than Debian packages (or RPMs for that matter).
jeromenerf 5y ago
If I was asked how a Linux distribution and package management should work, I would probably describe something very different to Debian, because of all the bureaucracy involved, yet I have been happily using Debian for everything for more than 20 years.
akagusu 5y ago
I use Debian for desktop and server since Woody, but recently I switched to Void for desktop because it is easier to build custom packages. It is 2021 and it still is a PITA to build custom Debian packages. Debian is a rock solid distro and I think people would use it more if package management was better.
krrishdhaneja 5y ago
Is there any way to enable it on ubuntu?

86 points by luke2m 5y ago

I'm excited to see someone is working on this. I have considered switching from Arch to Sid in the past, mainly so that I could run the same OS on all computers and because I like the DFSG. Two things have stopped me: * It's so much harder to build your own software packages on Debian. Even patching an existing Debian package can be painful, and having to write your own packages is even worse. I'm sure a dedicated enough user can learn to use the Debian packaging software proficiently, but it's a huge barrier to entry when I have something as easy as Arch's PKGBUILD syntax at my disposal. It looks like this project is interested in solving this problem: rather than using Debian's packaging tools for the DUR, it actually appears to literally be using makepkg with a Debian conversion script running on top. [1] * The systemd integration is currently quite bad. It's probably the source of a bunch of user complaints about systemd. Debian's systemd install currently still supports [2] and uses init scripts and update-rc.d, the very thing unit files were supposed to take us beyond. In fact, a pretty minimal Debian installation I have on a server has 14 init scripts, while my Arch install doesn't even have an /etc/init.d directory! On the whole, Debian administration is a lot more complicated than on Arch because of the relative complexity of the architecture. [1] https://docs.hunterwittenborn.com/makedeb/makedeb/intro https://docs.hunterwittenborn.com/makedeb/makedeb/intro [2] https://wiki.debian.org/Teams/pkg-systemd/Integration https://wiki.debian.org/Teams/pkg-systemd/Integration

spinax 5y ago
I agree, RPM is similarly just as easy amongst others who all sort of stick to a single control file design. This exact DEB ergonomic pain of files all over the place keeps me at arms length, it's clunky (to me) and the build process weirds me out with how many variations on tools used to get the same result. It's backwards compatible as all get go, I'll give you that.
zxzax 5y ago
>It's so much harder to build your own software packages on Debian. Even patching an existing Debian package can be painful, and having to write your own packages is even worse. I can't say that's been my experience, once I figured out dh_make [0] that made it pretty easy by handling most of the boilerplate. Building an existing package is as simple as doing `apt source` and then `dpkg-buildpackage` to rebuild it (you may have to do `apt build-dep` first too). I agree with the rest of your comments though. Edit: I haven't looked into the details of how it works but I would imagine that YMMV with trying to use makepkg that way. The hard part here isn't getting the packages to build, it's in reconciling the library dependencies across all the tens of thousands of packages that make up both distros. [0]: https://blog.packagecloud.io/eng/2015/07/14/using-dh-make-to-prepare-debian-packages/ https://blog.packagecloud.io/eng/2015/07/14/using-dh-make-to...
- bscphil 5y ago
  Yeah, I'm vaguely aware of various wrappers that try to make the process easier, I should probably give those a try. Building an existing package is certainly very easy, but I've had problems trying to download the source, apply a patch, and then rebuild it. In Arch this is just "makepkg -o" then "makepkg -e" after you patch the source.
  - zxzax 5y ago
    Really? For me it's literally just `dpkg-buildpackage` after patching the source. I never had any problems with it.
    - corndoge 5y ago
      What package and how complex is it?
      - zxzax 5y ago
        I'm not sure I understand the question? This is for any package. Of course you will run into trouble if you introduce breakage, like removing files that the build script expects to be there, or causing merge conflicts with patches applied by the build script. But those breakages can happen with any package manifest, including PKGBUILD.
        namibj 5y ago
        makepkg -o already applies patches. And makepkg -e after it is like calling it normally, if you don't touch anything in-between.
        zxzax 5y ago
        The difference there is that debhelper will usually try to keep its own modifications temporary, and otherwise keep the source in the same state as the original upstream source. So that way you know when there is going to be a merge conflict.
thayne 5y ago
> The systemd integration is currently quite bad. It's probably the source of a bunch of user complaints about systemd. I haven't used plain Debian, but this has been my experience with Ubuntu. Almost all the problems I've run into with systemd have been because of an interaction with init.d scripts that should be systemd units, or similar. My biggest complaint is that while systemd-resolved is supposed to be optional, on Ubuntu it is practically impossible to fully disable without breaking things, and disabling is officially "unsupported". On archlinux, if you want to use dnsmasq instead it is just a matter of disabling one service and enabling the other.
- mst 5y ago
  This is actually something that keeps tempting me to try arch, since it having gone all-in on systemd early on would hopefully give me a more 'native' systemd experience and help me figure out which of my gripes are with systemd and which of them are with how-$distro-added-systemd. Thing is, I'd only want such an install for playing around with occasionally and as the argument upthread makes pretty clear, "doing a bulk upgrade occasionally" is something that really isn't regarded as a sensible way to run arch.
  - bscphil 5y ago
    I do my upgrades every few weeks, for what it's worth, and I've had the same Arch install since 2013. The size of the upgrade should very rarely have any effect on whether it succeeds; you're just more likely to have missed some major changes if you're upgrading without checking the latest news from the website. Partial updates are also unsupported, and in my experience that's the most common way people break things.
throwawaaarrgh 5y ago
> On the whole, Debian administration is a lot more complicated than on Arch because of the relative complexity of the architecture. This should be expected though. Debian has been around a lot longer and is depended on by more of the Linux world. Complexity is a natural outcome of more stakeholder requirements (more stakeholders = more requirements = more complexity). I won't get into the systemd holy war, but suffice to say that comparing the architecture of init scripts vs systemd is like comparing the design of a bicycle to a car. One most definitely is more complex than the other, but whether that's a good thing or not depends on what you want to do with it.
- kijin 5y ago
  It's okay to ride a bicycle instead of a car, or vice versa. It's not okay to put bicycle tires on a car, or a car transmission on a bicycle. I have no complaints about distros that are either 100% systemd or 100% init scripts. The problem with Debian (and its derivatives) is that they're trying to maintain both at the same time. If they really want to support both "/etc/init.d/servicename start" and "systemctl start servicename" commands, one should be turned into an empty shell that simply invokes the other, like what Red Hat did with the "service" command. The current system kinda works out of the box, but goes out of sync as soon as you try to customize either the init script or the unit file.
  - andrewshadura 5y ago
    In fact, init scripts are only used by systemd when there are no corresponding native unit files.
    - kijin 5y ago
      A lot of debian packages supply both systemd unit files and init scripts. You can use either to step on the other's foot.
      - andrewshadura 5y ago
        As I said, init scripts are only used if there's no unit file. If there's a systemd unit, the init script is ignored.
mjw1007 5y ago
The inconvenience goes further than building in the first place. If I want to try running a Debian package with an experimental patch as a one-off, I haven't found it too hard to build my own version. But AFAIK there's nothing that helps me manage the necessary work to rebuild with the same patch when a new distribution version comes along. Do source-based distributions have a good solution for this?
- andrewshadura 5y ago
  If you use Git, you just run git merge. If not, uupdate gives a good enough result for further fine tuning.
nextlevelwizard 5y ago
This is off-topic, but the reason why I stay away from Arch is that it has not once, but twice, just fucked itself from right under me. First time around I was just getting up and running and as I installed python3 there was some mismatch between some very core libraries and I couldn't roll back since the library in question wasn't available anywhere, but python3 package (or something that came along with it) was linked against the old one. Only "work around" I found was to symlink the current lib to the old's path. Second time I just just running bog standard fetch & update. Then I rebooted as is normal after you update and it no longer booted. Arch is fine hobbyist distro and you for sure have to live on he edge, but I wouldn't use it for anything you expect to be able to use every day at a moments notice.
- spinax 5y ago
  > Arch is fine hobbyist distro and you for sure have to live on he edge, but I wouldn't use it for anything you expect to be able to use every day at a moments notice. I disagree 100%. This laptop I'm typing from now was installed 2014-07-06, it's my main personal machine with all the random things your typical desktop does and it works great. I similarly used a work laptop almost as long until I was forced off Arch for compliance reasons this year (sigh). Your anecdotal failures are not everyone's experience, definitely not mine.
  - hjek 5y ago
    > This laptop I'm typing from now was installed 2014-07-06, It goes beyond anecdotal evidence. I mean, if you look at the Arch news feed[0], there are a good few updates since then that are labelled "requires manual intervention". I like Arch and it's great they're posting those notices, but I don't think it can be claimed that upgrading an on-the-edge system is always problem free. [0] https://archlinux.org/news/ https://archlinux.org/news/
    - spinax 5y ago
      This is part of the agreement for using Arch, it's not a system you can ignore, you must actually pay attention to these news items. The upgrade tool I use actually shows new news to you front and center when performing an upgrade so you're blatantly aware that you have to follow instructions. Those are not "problems", they are "following instructions to keep up with changes." If you wand a distro to just ignore and hope it all goes well, Arch is not for you. Never was.

brainless 5y ago

Nice effort, the Arch User Repository is one of the benefits of the Arch way I feel. I have become so used to simply search "arch aur <VS Code>" or whatever I am looking for, finding it there, git clone and install. I keep installing random userspace software and I do not think AUR let me down. On a side note, I keep thinking there are so many great ideas spread over the many Linux distributions and not having a single joint effort makes it hard from an adoption point. I love having choice but I would really like more users to be able to use a (any) distribution.

da_big_ghey 5y ago
If you are think search and git clone are nice, waiting until you find out of AUR helper! `paru -Syu visual-studio-code-bin`
- doubleunplussed 5y ago
  It's almost certainly a conscious choice to not use an AUR helper
  - brainless 5y ago
    I agree it is a conscious choice, I read it from the Arch Wiki, but to be honest I do not know why this can not be solved and accepted as a way forward.
christophilus 5y ago
I’ve only just started running Arch. One thing I don’t understand is the AUR security model. Aren’t you running arbitrary code / binaries built by some stranger on the interwebs on your machine? This is my biggest hesitation, and why I haven’t used AUR.
- spinax 5y ago
  Using the 80/20 rule, most AUR packages are simply the build script ("PKGBUILD") instructions and perhaps a patch if required, etc. (or say adding a missing .desktop file). The process involves your AUR tool (I use "pikaur") downloading them, then executing the build instructions _locally_ on your device. So your desktop is actually the one downloading the real source code and compiling it, then installing it. The 20% side of this is yes, there are some prebuilt binaries in AUR - usually because (a) they are vendor proprietary code with no source (Zoom, for example) or (b) so insane to build that the vendor does it and you use their binaries (Firefox for example - it's a monster to compile). Most of the time these packages are clearly labeled, usually with "-bin" in the name so you can easily avoid them. You are executing build instructions written by someone else, but the tools encourage you to actually review them (and pikaur for example can show them to you for review right then and there). There is a level of trust involved and yeah, bad actors do try and slip in ugly things but they're usually found pretty quickly because folks are actually reviewing-before-installing as encouraged. It's risk management on this one, you take some personal responsibility for using AUR to pay attention.

akdor1154 5y ago

Took a while to work out what this was - nice intro at https://docs.hunterwittenborn.com/makedeb/debian-user-repository/intro https://docs.hunterwittenborn.com/makedeb/debian-user-reposi....

AussieWog93 5y ago

Linux does not need more package managers. It creates nothing but support burdens and busywork for developers (yes, user repositories too). I don't understand what people expect to achieve by further fragmenting a minority OS that makes up only 3% of Desktop users.

brainless 5y ago
- Market share is not the most important metric, resilience matters and Linux distributions have only gained in acceptance over years - People have a fear or even aversion toward experiments since it needs effort, but some folks are simply geeks - they will keep trying and more power to them - Some of these experiments, historically, have brought some of the best open innovations in the industry and moved even closed-source rooted companies to change mindset - Fragmentation is a marketing problem IMHO and I would like to see some ground between that and a consolidated Linux distro but it will not happen easily and that is OK - The enthusiasts like us do not need every other mainstream user on Linux but I am sure we would love that (I am a Linux user for 18 years) - This community is happy learning and trying new things, it is joyful So, more power to experimentors. The value of this community is in choice in a market that is dominated by the Apples and Microsofts who do not care about choice.
- AussieWog93 5y ago
  I do get where you're coming from; this project just highlighted some personal frustrations I have with Desktop Linux is. I really wish we could have an open-source OS that was reliable and user-friendly for consumers (especially given how user-hostile Windows has become in the last 5 years), while similarly being non-burdensome for devs to deploy software to (which, to be fair, has improved a lot recently thanks to AppImageKit et al).
TheFreim 5y ago
Linux does need more package managers. Why? Because I like trying out new package managers and they don't harm people since they're not required to try or use them.

symlinkk 5y ago

Snap and Flatpak made distro specific user repositories like this obsolete

akvadrako 5y ago
Only for apps. They aren't really suited for libraries or even command line tools.
- forgotpwd16 5y ago
  Not suited but possible. Snap allows packaging both libraries (e.g. GNOME runtime libraries) and command line tools (e.g. htop). Although those will live under /snap rather on common Unix paths (/usr/lib and /usr/bin), it just means those will work across distros rather on a specific one.

usr1106 5y ago

Can anybody explain me what is the purpose of the element-desktop-bin package? It just takes the binary from the packages.riot.im repo. That's what I do, too, by having packages.riot.im in my sources.list.d. Why repackage it?

encryptluks2 5y ago
I can't say for sure, but my take is that this repo is designed to use Arch-style PKGBUILD packaging. So, it appears to simply be an alternative package that uses the Arch-style packaging.

tapia 5y ago

I think this is great. I am an arch user at home, but at work I use Ubuntu. It is really difficult sometimes to get the latest version of a software installed in an easy way. I tend to use a lot of custom Makefiles for this, but I don't really like to not use the package manager. Being an arch user, I always wished it was as easy to build deb packages as it is to build packages with makepkg. I tried the debian way, and could successfully build some packages, but it is not at easy at using PKGBUILD files and I have to eventually. Now it seems to be possible to do this in Ubuntu! I will definitely try this!

e3bc54b2 5y ago
These days I just use Nix/Guix on work machines and get to using latest versions in less than 5 minutes. At home I've switched fully to NixOS.

aorth 5y ago

Interesting and cool idea. In my experience Arch Linux PKGBUILDs are easier and more straightforward to write than Debian packages (or RPMs for that matter).

jeromenerf 5y ago

If I was asked how a Linux distribution and package management should work, I would probably describe something very different to Debian, because of all the bureaucracy involved, yet I have been happily using Debian for everything for more than 20 years.

akagusu 5y ago

I use Debian for desktop and server since Woody, but recently I switched to Void for desktop because it is easier to build custom packages. It is 2021 and it still is a PITA to build custom Debian packages. Debian is a rock solid distro and I think people would use it more if package management was better.

krrishdhaneja 5y ago

Is there any way to enable it on ubuntu?