73 ms·

Well certainly part of it is much of the .deb ecosystem still feels like its stuck in the late 90s linux era to me. But maybe I'm alone on that gut feel.

by bfrog 3y ago

__float 3y ago
"stuck in the late 90s" in what sense? Building them? Distributing them? (Dependencies?)
- Zetobal 3y ago
  I would say the process on getting "maintainer" status.
- deleted 3y ago
  [deleted]
- gorjusborg 3y ago
  That they work reliably?
  - bfrog 3y ago
    They work reliably with a lot of unseen work. Debian is a great distro as a user. The .deb packaging tools I found to be a huge hassle and made packaging up missing or updated or custom software a pain in the ass.
    - klysm 3y ago
      Exactly, this is why it takes literally years of human effort to get a new version released
- bfrog 3y ago
  Have you built a .deb with debuild and debhelpers? Can you recall all the goofy rules about what needs to go in each file and what each debhelper does? How do you keep all of it in version control and build downstream packages that depend on the changed one? Have you managed to accidently sneak a local build machine dependency or piece of information by accident into the final .deb only to realize it much later? I found it be a big ball of easily forgettable twine of rules tools and oddities myself that every time I needed to redo something was a hassle. With many foot guns that lead to odd package issues.
  - klysm 3y ago
    Completely agree with your assessment of the building process. The majority of the complexity involved in the process is not inherent
cswhnjidd 3y ago
Better being in the 90s than using snappacks or whatever.
reactordev 3y ago
Yes but at least I don’t see ads on my Operating System for Viagra. I’ll take 90s boring linux over windoze everyday of the week.
switch007 3y ago
Deb packages just need reinventing by some younger people. I’m thinking: implemented in nodejs with a cli with emojis and animations. The GitHub read me should have a minimum of 80 emojis and a meme or two. The core dependency of the cli should be a 6 month old framework with 92 commits. When that library reaches 1 year old, it should be swapped out for something newer as the sole maintainer will have left their job and/or got bored with the project having spent so long on it
- klysm 3y ago
  Excellent straw man takedown
Narann 3y ago
> the .deb ecosystem still feels like its stuck in the late 90s linux era to me. Can you elaborate, please? What do you mean by this?
- klysm 3y ago
  Quirky, clunky tooling with a bunch of arbitrary shit you have to memorize to use correctly. People enjoy that kind of thing after they learn it.
  - imp0cat 3y ago
    Enjoy? No. But yeah, it gets easier once you've done it a few times.
    - klysm 3y ago
      Not really enjoy doing, but enjoy knowing arcane shit even if it doesn't make sense.
      - Narann 3y ago
        Have you anything to point? I don’t remember any non-sense in packaging a deb.
hyperman1 3y ago
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

Well certainly part of it is much of the .deb ecosystem still feels like its stuck in the late 90s linux era to me. But maybe I'm alone on that gut feel.

by bfrog 3y ago

Well certainly part of it is much of the .deb ecosystem still feels like its stuck in the late 90s linux era to me. But maybe I'm alone on that gut feel.

__float 3y ago

"stuck in the late 90s" in what sense? Building them? Distributing them? (Dependencies?)

Zetobal 3y ago
I would say the process on getting "maintainer" status.
deleted 3y ago
[deleted]
gorjusborg 3y ago
That they work reliably?
- bfrog 3y ago
  They work reliably with a lot of unseen work. Debian is a great distro as a user. The .deb packaging tools I found to be a huge hassle and made packaging up missing or updated or custom software a pain in the ass.
  - klysm 3y ago
    Exactly, this is why it takes literally years of human effort to get a new version released
bfrog 3y ago
Have you built a .deb with debuild and debhelpers? Can you recall all the goofy rules about what needs to go in each file and what each debhelper does? How do you keep all of it in version control and build downstream packages that depend on the changed one? Have you managed to accidently sneak a local build machine dependency or piece of information by accident into the final .deb only to realize it much later? I found it be a big ball of easily forgettable twine of rules tools and oddities myself that every time I needed to redo something was a hassle. With many foot guns that lead to odd package issues.
- klysm 3y ago
  Completely agree with your assessment of the building process. The majority of the complexity involved in the process is not inherent

cswhnjidd 3y ago

Better being in the 90s than using snappacks or whatever.

reactordev 3y ago

Yes but at least I don’t see ads on my Operating System for Viagra. I’ll take 90s boring linux over windoze everyday of the week.

switch007 3y ago

Deb packages just need reinventing by some younger people. I’m thinking: implemented in nodejs with a cli with emojis and animations. The GitHub read me should have a minimum of 80 emojis and a meme or two. The core dependency of the cli should be a 6 month old framework with 92 commits. When that library reaches 1 year old, it should be swapped out for something newer as the sole maintainer will have left their job and/or got bored with the project having spent so long on it

klysm 3y ago
Excellent straw man takedown

Narann 3y ago

> the .deb ecosystem still feels like its stuck in the late 90s linux era to me. Can you elaborate, please? What do you mean by this?

klysm 3y ago
Quirky, clunky tooling with a bunch of arbitrary shit you have to memorize to use correctly. People enjoy that kind of thing after they learn it.
- imp0cat 3y ago
  Enjoy? No. But yeah, it gets easier once you've done it a few times.
  - klysm 3y ago
    Not really enjoy doing, but enjoy knowing arcane shit even if it doesn't make sense.
    - Narann 3y ago
      Have you anything to point? I don’t remember any non-sense in packaging a deb.

hyperman1 3y ago

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