4 ms·

I've used Debian since 1994 and can't recall a single package installation or removal which exhibited any problem this discussion claims to be solving.

numbsafari 8y ago
Yes, but we now live in a world of weaponized package takovers, such as the Kite incident with IDE plugins, or the security mishaps that have afflicted npm. The “I’m a good guy, you’re a good guy, we’re all good guys” approach doesn’t really cut it any longer.
- stephenr 8y ago
  I'm unfamiliar with 'the Kite incident' but the NPM incidents have been due to a) the ass-backwards approach the company took to building a package manager. b) the new development paradigm of "fuck it, find a library". Flying Spaghetti monster forbid these hipster developers actually have to write some fucking code themselves, its easier just to duct-tape together 200 different 'libraries', half of which do what you could do in 5 lines or less, and produces a dependency tree like fucking crab grass.
  - gronne 8y ago
    A bit ranty but i’l allow it because you are right. All praise his noodleness.
  - wlesieutre 8y ago
    For reference on Kite: https://forum.sublimetext.com/t/rfc-default-package-control-channel-and-package-telemetry/30157 https://forum.sublimetext.com/t/rfc-default-package-control-...
  - coleifer 8y ago
    Thankfully they mostly stay in their own little excrement filled sandbox.
scbrg 8y ago
Packages in the official Debian archives are generally well behaved. Unofficial packages, sometimes less so. There was an incident a couple of months ago where a package (from Microsoft, incidentally) replaced your /bin/sh with bash. Wouldn't it be neat if such an atrocity wasn't possible?
- isostatic 8y ago
  But you'd spot that when you look at the package before you install it.
- rlpb 8y ago
  "Unofficial packages" aren't really in the set of supported dpkg use cases. They're a hack that fail in the general case because there are various things they can't express because the expression of them comes from the other side of the package relationship (eg. Breaks/Replaces), and official packages don't declare such things for packages outside the Debian archive. Therefore external packages are fundamentally broken, but third parties keep using them because better alternatives haven't existed in the past. > Wouldn't it be neat if such an atrocity wasn't possible? An easier way might be to make it difficult for users to install "unofficial packages", but that would be against the philosophy of users having ultimate control over their systems. Your suggestion puts us in the rather interesting situation that you're requesting a new feature for something that primarily affects third party packages that aren't actually supported in the first place.
jankotek 8y ago
And I experienced hundreds of problems. It really depends on what you are doing.
isostatic 8y ago
I build many small pacakges and have made a few postinst files which occasionally break and leave apt in an upset state, typically when auto-installed by the preseed while trying to do horrible things to files (like editing snmpd.conf). These aren't packages that follow the guidelines though, they're just internal ones I build for a small number of installs, and only ends up with an unconfigured pacakge. I've never seen an external package that accidently causes problems. Postinsts and other control files should on the whole be really simple. This post seems to be more about protecting users from accidental problems with package installation scripts, but not about deliberate problems with packages, nor accidental problems with packages post installation script. When I take an untrusted .deb, I look inside at the files it's dumping out, and the scripts it's going to run. Making apt more declarative wouldn't stop that.
always_good 8y ago
Well, one problem is that apt-get's uninstall doesn't undo everything that could have happened during install. It's just like how you need software like Revo Uninstaller on Windows to actually clean up everything: why? It might not cause you day-to-day problems, but it's a massive defect in my eyes.
IronBacon 8y ago
I don't have the link at hand but a few years ago (so I'm probably wrong about the details) I think a Debian developer was annoyed by the misuse of his personal repository that he modified his deb packages to change the user desktop background, mostly to demonstrate that installing random unknown packages from the Interweb could be dangerous. I recall that episode made some noise at the time...

numbsafari 8y ago

Yes, but we now live in a world of weaponized package takovers, such as the Kite incident with IDE plugins, or the security mishaps that have afflicted npm. The “I’m a good guy, you’re a good guy, we’re all good guys” approach doesn’t really cut it any longer.

stephenr 8y ago
I'm unfamiliar with 'the Kite incident' but the NPM incidents have been due to a) the ass-backwards approach the company took to building a package manager. b) the new development paradigm of "fuck it, find a library". Flying Spaghetti monster forbid these hipster developers actually have to write some fucking code themselves, its easier just to duct-tape together 200 different 'libraries', half of which do what you could do in 5 lines or less, and produces a dependency tree like fucking crab grass.
- gronne 8y ago
  A bit ranty but i’l allow it because you are right. All praise his noodleness.
- wlesieutre 8y ago
  For reference on Kite: https://forum.sublimetext.com/t/rfc-default-package-control-channel-and-package-telemetry/30157 https://forum.sublimetext.com/t/rfc-default-package-control-...
- coleifer 8y ago
  Thankfully they mostly stay in their own little excrement filled sandbox.

scbrg 8y ago

Packages in the official Debian archives are generally well behaved. Unofficial packages, sometimes less so. There was an incident a couple of months ago where a package (from Microsoft, incidentally) replaced your /bin/sh with bash. Wouldn't it be neat if such an atrocity wasn't possible?

isostatic 8y ago
But you'd spot that when you look at the package before you install it.
rlpb 8y ago
"Unofficial packages" aren't really in the set of supported dpkg use cases. They're a hack that fail in the general case because there are various things they can't express because the expression of them comes from the other side of the package relationship (eg. Breaks/Replaces), and official packages don't declare such things for packages outside the Debian archive. Therefore external packages are fundamentally broken, but third parties keep using them because better alternatives haven't existed in the past. > Wouldn't it be neat if such an atrocity wasn't possible? An easier way might be to make it difficult for users to install "unofficial packages", but that would be against the philosophy of users having ultimate control over their systems. Your suggestion puts us in the rather interesting situation that you're requesting a new feature for something that primarily affects third party packages that aren't actually supported in the first place.

jankotek 8y ago

And I experienced hundreds of problems. It really depends on what you are doing.

isostatic 8y ago

I build many small pacakges and have made a few postinst files which occasionally break and leave apt in an upset state, typically when auto-installed by the preseed while trying to do horrible things to files (like editing snmpd.conf). These aren't packages that follow the guidelines though, they're just internal ones I build for a small number of installs, and only ends up with an unconfigured pacakge. I've never seen an external package that accidently causes problems. Postinsts and other control files should on the whole be really simple. This post seems to be more about protecting users from accidental problems with package installation scripts, but not about deliberate problems with packages, nor accidental problems with packages post installation script. When I take an untrusted .deb, I look inside at the files it's dumping out, and the scripts it's going to run. Making apt more declarative wouldn't stop that.

always_good 8y ago

Well, one problem is that apt-get's uninstall doesn't undo everything that could have happened during install. It's just like how you need software like Revo Uninstaller on Windows to actually clean up everything: why? It might not cause you day-to-day problems, but it's a massive defect in my eyes.

IronBacon 8y ago

I don't have the link at hand but a few years ago (so I'm probably wrong about the details) I think a Debian developer was annoyed by the misuse of his personal repository that he modified his deb packages to change the user desktop background, mostly to demonstrate that installing random unknown packages from the Interweb could be dangerous. I recall that episode made some noise at the time...