3 ms·

I'd like you to explain this a bit deeper. As a user from the '90s I am quite happy with it, but I might be stuck in my ways, who knows? So not saying you're

I'd like you to explain this a bit deeper. As a user from the '90s I am quite happy with it, but I might be stuck in my ways, who knows? So not saying you're wrong, but what are we missing exactly?

em-bee 3y ago
what deb and rpm and any similar packaging are missing is true version control of the whole packaging ecosystem. at present it is difficult to track which combination of package versions has been tested, and you can't easily roll back to a tested combination. the current systems assume that versioning is linear and that a newer version of any package is always better than an older version. downgrading any package so that every user of the distribution can benefit from the downgrade is difficult and confusing. there are distributions that provide rollback. but as far as i can tell they require you to keep the old version to roll back to, stored on your computer. you can't roll back otherwise. i really want this to work like revision systems for code, where i can just checkout any old version that was committed. another feature that i would like to see everywhere is stickiness of the packaging source. currently, if i include additional repos they override the main repo, such that always the newest version is picked from any repo. this makes it difficult to include less trusted 3rd party repos. i would like to be able to add 3rd party repos such that only the packages that i explicitly install from that repo will also be updated from that repo, while any other packages in that repo will be ignored unless no other repo has them. in debian it is possible to set priorities for different repos, but that is not easy to manage. the priorities to have each package update stick to the original repo should be default. guix and nix do provide some of this as far as i can tell, but i am not a fan of keeping every package self contained with massive link trees. (i may change my mind on that some time maybe, but that's what i feel for now) conary was/(is?) a packaging system that did have both of these features, although, according to some of the developers the repository was a bit clunky and could have been better. but that was under the hood, not noticeable to users and packagers. i loved working with it and i wish foresight, the distribution using it had become more popular so that it would have had the manpower to keep going.
- pabs3 3y ago
  With snapshot.debian.org you can roll back to any version of any package that has been saved. Using that you can even bisect where issues started. https://manpages.debian.org/testing/devscripts/debbisect.1.en.html https://manpages.debian.org/testing/devscripts/debbisect.1.e... https://wiki.debian.org/BisectDebian https://wiki.debian.org/BisectDebian
- pabs3 3y ago
  You can use pinning to achieve what you want with 3rd-party repos, using the origin feature. https://wiki.debian.org/AptConfiguration#apt_preferences_.28APT_pinning.29 https://wiki.debian.org/AptConfiguration#apt_preferences_.28...
klysm 3y ago
A few of my gripes: * creating Debian packages is a difficult process to learn. There’s a bunch of tools and wrappers around those tools to handle inadequacies and it’s not clear how to do it “right”. For example, if I just have a binary and want to put it into a Debian package without pulling in some random shell scripts that aren’t part of Debian proper, it’s not immediately clear how to do that. * Non-atomic and imperative install/remove/etc. hooks make it difficult to robustly handle failures. Since there is no file system manifest or sandboxing, there’s no real guarantees that removing a package will actually remove it. * there’s no spec for a .deb package. This means the only way to correctly generate a Debian package is through the difficult tooling. I understand why this choice is made, and it has a lot of benefits for the continued evolution of the debian project. However, it makes it difficult to build better tooling around deb packages.
- pabs3 3y ago
  The spec for .deb packages is in the deb(5) manual page: https://manpages.debian.org/bookworm/dpkg-dev/deb.5.en.html https://manpages.debian.org/bookworm/dpkg-dev/deb.5.en.html
  - klysm 3y ago
    That's not a 'spec' - it's a vague description of the archive names.
    - pabs3 3y ago
      It and the other manual pages linked from it contain everything you need to make a .deb from scratch.
      - klysm 3y ago
        I can’t find it right now, but the Debian docs explicitly indicate that you shouldn’t do that because the internal format is not stable. It has changed significantly in the past, and the only “supported” way to do it is with the official Debian tools

I'd like you to explain this a bit deeper. As a user from the '90s I am quite happy with it, but I might be stuck in my ways, who knows? So not saying you're wrong, but what are we missing exactly?

em-bee 3y ago

what deb and rpm and any similar packaging are missing is true version control of the whole packaging ecosystem. at present it is difficult to track which combination of package versions has been tested, and you can't easily roll back to a tested combination. the current systems assume that versioning is linear and that a newer version of any package is always better than an older version. downgrading any package so that every user of the distribution can benefit from the downgrade is difficult and confusing. there are distributions that provide rollback. but as far as i can tell they require you to keep the old version to roll back to, stored on your computer. you can't roll back otherwise. i really want this to work like revision systems for code, where i can just checkout any old version that was committed. another feature that i would like to see everywhere is stickiness of the packaging source. currently, if i include additional repos they override the main repo, such that always the newest version is picked from any repo. this makes it difficult to include less trusted 3rd party repos. i would like to be able to add 3rd party repos such that only the packages that i explicitly install from that repo will also be updated from that repo, while any other packages in that repo will be ignored unless no other repo has them. in debian it is possible to set priorities for different repos, but that is not easy to manage. the priorities to have each package update stick to the original repo should be default. guix and nix do provide some of this as far as i can tell, but i am not a fan of keeping every package self contained with massive link trees. (i may change my mind on that some time maybe, but that's what i feel for now) conary was/(is?) a packaging system that did have both of these features, although, according to some of the developers the repository was a bit clunky and could have been better. but that was under the hood, not noticeable to users and packagers. i loved working with it and i wish foresight, the distribution using it had become more popular so that it would have had the manpower to keep going.

pabs3 3y ago
With snapshot.debian.org you can roll back to any version of any package that has been saved. Using that you can even bisect where issues started. https://manpages.debian.org/testing/devscripts/debbisect.1.en.html https://manpages.debian.org/testing/devscripts/debbisect.1.e... https://wiki.debian.org/BisectDebian https://wiki.debian.org/BisectDebian
pabs3 3y ago
You can use pinning to achieve what you want with 3rd-party repos, using the origin feature. https://wiki.debian.org/AptConfiguration#apt_preferences_.28APT_pinning.29 https://wiki.debian.org/AptConfiguration#apt_preferences_.28...

klysm 3y ago

A few of my gripes: * creating Debian packages is a difficult process to learn. There’s a bunch of tools and wrappers around those tools to handle inadequacies and it’s not clear how to do it “right”. For example, if I just have a binary and want to put it into a Debian package without pulling in some random shell scripts that aren’t part of Debian proper, it’s not immediately clear how to do that. * Non-atomic and imperative install/remove/etc. hooks make it difficult to robustly handle failures. Since there is no file system manifest or sandboxing, there’s no real guarantees that removing a package will actually remove it. * there’s no spec for a .deb package. This means the only way to correctly generate a Debian package is through the difficult tooling. I understand why this choice is made, and it has a lot of benefits for the continued evolution of the debian project. However, it makes it difficult to build better tooling around deb packages.

pabs3 3y ago
The spec for .deb packages is in the deb(5) manual page: https://manpages.debian.org/bookworm/dpkg-dev/deb.5.en.html https://manpages.debian.org/bookworm/dpkg-dev/deb.5.en.html
- klysm 3y ago
  That's not a 'spec' - it's a vague description of the archive names.
  - pabs3 3y ago
    It and the other manual pages linked from it contain everything you need to make a .deb from scratch.
    - klysm 3y ago
      I can’t find it right now, but the Debian docs explicitly indicate that you shouldn’t do that because the internal format is not stable. It has changed significantly in the past, and the only “supported” way to do it is with the official Debian tools