5 ms·

Is "very slow depsolving" even relevant? In my experience that part of installation and remove is a very small part of the overall installation or removal time

Is "very slow depsolving" even relevant? In my experience that part of installation and remove is a very small part of the overall installation or removal time and goes by so fast I've never really noticed it. Even if dnf and zypper are 1000x faster than apt there, that alone wouldn't convince me to use them.

StavrosK 11y ago
Not only that, but it sounds like someone can just add a solver to apt, whereas repackaging the entire linux ecosystem to use a different format is going to be a bit more difficult.
- detaro 11y ago
  These distros use RPM for decades (or at least more than one) now, for them switching to apt would be repackaging everything. There seems to be an apt-fork for RPM, but that hasn't been updated in years.
  - StavrosK 11y ago
    I guess it's true that one wouldn't be able to just install debs on RedHat, for example, without modification. Alas.
- rwmj 11y ago
  Red Hat (the company) and RPM (the format) predate Debian, although only by a few months. Also RPM is a much better format than deb, and that's speaking as someone who regularly makes packages using both. I would also say that dnf and zypper are better package managers than apt, in as much as they are faster and easier to automate. Compare the code here: https://github.com/libguestfs/libguestfs/blob/1.29.43/customize/customize_run.ml#L94 https://github.com/libguestfs/libguestfs/blob/1.29.43/custom...
  - lqdc13 11y ago
    What? how is this better? what all of this is is apt making users say yes to everything such as config changes. I'm totally fine with that. Sure it's an extra line or 2 when automating, but I don't see it as bad.
    - jetpks 11y ago
      I don't know about you, but I'd rather use the tool that I don't have to hack the training wheels off of first when I'm trying to update 100,000 machines to mitigate a critical security issue.
      - acdha 11y ago
        1. Security updates don't add debconf prompts 2. Supporting large numbers of systems is exactly when a persistent local configure database becomes useful for avoiding unanticipated regressions
  - Aloha 11y ago
    For those of us uninformed, why is RPM a better format than deb?
    - rwmj 11y ago
      Primarily the all-in-one spec file is a lot easier to read and write than the scattered files of deb. Also the build system is considerably simpler and more coherent -- you don't have the mess of dh vs cdbs vs flavour of the month. RPM has a nice language and macro system. It's not that deb is bad, just that when I have to package for both, I find the RPM one simpler and easier. Here is a relative simple package, done for both RPM and .deb. The RPM spec is 141 lines (excluding the changelog): http://pkgs.fedoraproject.org/cgit/virt-top.git/tree/virt-top.spec http://pkgs.fedoraproject.org/cgit/virt-top.git/tree/virt-to... The .deb is actually shorter in this case, but split over several files, and uses cdbs which I find infuriating with its lack of documentation and multiple hidden implicit rules. If you have a Debian machine around, try reading the /usr/share/cdbs/1/ files some time. Remember also that for most Debian packages, the files come in a tarball or even a patch, which makes them hard to manipulate without obscure deb-* commands. https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/virt-top.git/tree/debian https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/vir...
- edwintorok 11y ago
  There is apt-cudf which allows to use external solvers (such as aspcud) with apt.
benjiweber 11y ago
As well as being a lot faster than apt, the biggest advantage of openSUSE package management stack to me is that it plays nicely with third party vendors. Packages have sticky-vendors, so you only get updates from the same vendor unless you choose to switch. Even if another the update is in a different package repository. This means you don't get flip-flopping package vendors when the same package is available from two vendors and they release updates one after each other. Another example is the tooling around package/repository signing - Letting the user decide whom to trust without making them jump through hoops to manually import keys. There's also a lot of things in the packaging itself designed to help support third party vendors. Dependencies tend to be configured with capabilities rather than package names. e.g. The kernel provides information about the binary api version which third party drivers can depend on. Third party kernel modules can also supplement/enhance (soft dependencies - inverse recommends/suggests) specific PCI ids so the solver will suggest installing them if available and compatible with your hardware. In my view debian package management "just works" because the set of packages is carefully curated and tested, there's a high standard of package quality, and everything is available in one place. PPAs can present problems. The rpm distro ecosystem philosophy is somewhat different. It's impractical to expect a single organisation to package all the software you will ever need, so let's provide tools to help software from multiple vendors to get along.
- vacri 11y ago
  Apt pinning gives you the same functionality as sticky vendors - though it may be a bit more fiddly to implement (I'm unfamiliar with openSUSE PMs)
raverbashing 11y ago
> Is "very slow depsolving" even relevant? Try upgrading from major versions and seeing what happens. It's absolutely relevant
- pbhjpbhj 11y ago
  Rather than forcing us all to install an outdated distro and do a major version upgrade then trying to guess the particular element of the process you find disconcerting could you may be tell us?
- mpdehaan2 11y ago
  In server land, it's more common for machines to be rebuilt from scratch (or at least better to do so). Given, I understand some people want "servers like pets" and Linux desktop to be a thing, in industrial applications it's usually not an issue.
  - ploxiln 11y ago
    I've worked on a large website where all backend servers were running RHEL5. We had pretty good tooling, deployment, config management. We could launch and kill new physical and virtual servers with particular "roles". We did not, however, re-image servers for every deploy. Our deployment/configuration-management would make sure the correct versions of all things were installed, including stand-alone code, services under daemontools, crontab entries, system users, packages, and more. In most cases, no-longer-specified items would be removed. BTW ansible sucks for this aspect (I use it extensively at a new place) ;) My point is that, the modern attitude of "you can't trust what's on a server unless you build it from scratch or apply an image" is not the only valid way to do things, and is somewhat defeatist, like we're no better than windows where you can't guarantee that anything can be cleanly uninstalled / replaced. Is your package manager that bad? Yum being dog-slow was very annoying. Updating all server lists for every yum command was very annoying. I customized various modules and scripts to use "makecache" and "-C" where appropriate, but that was an annoying task. And yum was still slower than I'm accustomed to a linux package manager being. Finally having a couple of years experience with yum, I can confidently say that pacman (archlinux) and apt (debian) are worlds better. Maybe zypper and dnf make rpm not suck; I probably won't find out for a few years.

StavrosK 11y ago

Not only that, but it sounds like someone can just add a solver to apt, whereas repackaging the entire linux ecosystem to use a different format is going to be a bit more difficult.

detaro 11y ago
These distros use RPM for decades (or at least more than one) now, for them switching to apt would be repackaging everything. There seems to be an apt-fork for RPM, but that hasn't been updated in years.
- StavrosK 11y ago
  I guess it's true that one wouldn't be able to just install debs on RedHat, for example, without modification. Alas.
rwmj 11y ago
Red Hat (the company) and RPM (the format) predate Debian, although only by a few months. Also RPM is a much better format than deb, and that's speaking as someone who regularly makes packages using both. I would also say that dnf and zypper are better package managers than apt, in as much as they are faster and easier to automate. Compare the code here: https://github.com/libguestfs/libguestfs/blob/1.29.43/customize/customize_run.ml#L94 https://github.com/libguestfs/libguestfs/blob/1.29.43/custom...
- lqdc13 11y ago
  What? how is this better? what all of this is is apt making users say yes to everything such as config changes. I'm totally fine with that. Sure it's an extra line or 2 when automating, but I don't see it as bad.
  - jetpks 11y ago
    I don't know about you, but I'd rather use the tool that I don't have to hack the training wheels off of first when I'm trying to update 100,000 machines to mitigate a critical security issue.
    - acdha 11y ago
      1. Security updates don't add debconf prompts 2. Supporting large numbers of systems is exactly when a persistent local configure database becomes useful for avoiding unanticipated regressions
- Aloha 11y ago
  For those of us uninformed, why is RPM a better format than deb?
  - rwmj 11y ago
    Primarily the all-in-one spec file is a lot easier to read and write than the scattered files of deb. Also the build system is considerably simpler and more coherent -- you don't have the mess of dh vs cdbs vs flavour of the month. RPM has a nice language and macro system. It's not that deb is bad, just that when I have to package for both, I find the RPM one simpler and easier. Here is a relative simple package, done for both RPM and .deb. The RPM spec is 141 lines (excluding the changelog): http://pkgs.fedoraproject.org/cgit/virt-top.git/tree/virt-top.spec http://pkgs.fedoraproject.org/cgit/virt-top.git/tree/virt-to... The .deb is actually shorter in this case, but split over several files, and uses cdbs which I find infuriating with its lack of documentation and multiple hidden implicit rules. If you have a Debian machine around, try reading the /usr/share/cdbs/1/ files some time. Remember also that for most Debian packages, the files come in a tarball or even a patch, which makes them hard to manipulate without obscure deb-* commands. https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/virt-top.git/tree/debian https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/vir...
edwintorok 11y ago
There is apt-cudf which allows to use external solvers (such as aspcud) with apt.

benjiweber 11y ago

As well as being a lot faster than apt, the biggest advantage of openSUSE package management stack to me is that it plays nicely with third party vendors. Packages have sticky-vendors, so you only get updates from the same vendor unless you choose to switch. Even if another the update is in a different package repository. This means you don't get flip-flopping package vendors when the same package is available from two vendors and they release updates one after each other. Another example is the tooling around package/repository signing - Letting the user decide whom to trust without making them jump through hoops to manually import keys. There's also a lot of things in the packaging itself designed to help support third party vendors. Dependencies tend to be configured with capabilities rather than package names. e.g. The kernel provides information about the binary api version which third party drivers can depend on. Third party kernel modules can also supplement/enhance (soft dependencies - inverse recommends/suggests) specific PCI ids so the solver will suggest installing them if available and compatible with your hardware. In my view debian package management "just works" because the set of packages is carefully curated and tested, there's a high standard of package quality, and everything is available in one place. PPAs can present problems. The rpm distro ecosystem philosophy is somewhat different. It's impractical to expect a single organisation to package all the software you will ever need, so let's provide tools to help software from multiple vendors to get along.

vacri 11y ago
Apt pinning gives you the same functionality as sticky vendors - though it may be a bit more fiddly to implement (I'm unfamiliar with openSUSE PMs)

raverbashing 11y ago

> Is "very slow depsolving" even relevant? Try upgrading from major versions and seeing what happens. It's absolutely relevant

pbhjpbhj 11y ago
Rather than forcing us all to install an outdated distro and do a major version upgrade then trying to guess the particular element of the process you find disconcerting could you may be tell us?
mpdehaan2 11y ago
In server land, it's more common for machines to be rebuilt from scratch (or at least better to do so). Given, I understand some people want "servers like pets" and Linux desktop to be a thing, in industrial applications it's usually not an issue.
- ploxiln 11y ago
  I've worked on a large website where all backend servers were running RHEL5. We had pretty good tooling, deployment, config management. We could launch and kill new physical and virtual servers with particular "roles". We did not, however, re-image servers for every deploy. Our deployment/configuration-management would make sure the correct versions of all things were installed, including stand-alone code, services under daemontools, crontab entries, system users, packages, and more. In most cases, no-longer-specified items would be removed. BTW ansible sucks for this aspect (I use it extensively at a new place) ;) My point is that, the modern attitude of "you can't trust what's on a server unless you build it from scratch or apply an image" is not the only valid way to do things, and is somewhat defeatist, like we're no better than windows where you can't guarantee that anything can be cleanly uninstalled / replaced. Is your package manager that bad? Yum being dog-slow was very annoying. Updating all server lists for every yum command was very annoying. I customized various modules and scripts to use "makecache" and "-C" where appropriate, but that was an annoying task. And yum was still slower than I'm accustomed to a linux package manager being. Finally having a couple of years experience with yum, I can confidently say that pacman (archlinux) and apt (debian) are worlds better. Maybe zypper and dnf make rpm not suck; I probably won't find out for a few years.