4 ms·

Debian's 'synaptic'. Help and leverage it to other platforms, if needed. Less pain all around.

by ableal 17y ago

jeremymcanally 17y ago
I sincerely doubt porting that to other platforms would be very easy, but perhaps you and I have different definitions of "pain." :) Plus, you'd have to worry about minor-yet-annoying namespace issues (e.g., a Python package and a non-Python package sharing a name). Am I the only one not offended by the idea of package managers for each programming language? They always work better when they're tailored to the language.
- viraptor 17y ago
  There are cases when they don't work better. It happens when your non-python program requires something from python for scripting, or when a python module requires a 'classic' library. A global system is quite good in those cases. I'm not sure what you mean by the namespace issues. Everything that's installed as a python package in debian is prefixed with "python-"...
- ableal 17y ago
  About the porting and the pain: I believe the hard parts are defining the metadata, and refining the actual program logic. In my experience over the last decade, 'synaptic' has been the most trouble-free system to use. I think it would be less work to clone/port the needed logic bits to Windows/whatever, and share most of the metadata defined for Debian/Ubuntu/etc, instead of redoing (and debugging) everything from scratch.
- lucumo 17y ago
  > Am I the only one not offended by the idea of package managers for each programming language? Learning multiple tools to do a similar job is a bit of a nuisance. If you know one tool, you can learn its details over time. That's much harder with multiple tools. Does tool X remove configuration files when uninstalling? Can it even uninstall? Do I need to update some configuration files manually? There's also the part where you sometimes need integration with packages from other package manager systems. System libraries (libcurl, etc.), header files if it gets compiled at install time, make, a compiler, etc. But since the problem is getting solved by multiple tools already (cpan, pear, apt, yum, just plain ./configure+make, etc.), maybe we should work more on integrating those package managers and less on replacing the others. It seems unlikely to happen with so many incompatible personal preferences around...
blasdel 17y ago
Please god no. Apt itself is barely good enough to handle libraries written in C, much less a dynamic language with multiple potentially-incompatible runtimes, and Debian's policies are dead set against making anything remotely wholesome: * As an author, affected middlemen have a stranglehold on easy distribution * License wankery (fuck debian-legal) * Teenagers randomly patching upstream software without review * Shipping non-standard configurations, often with features randomly disabled * Rearranging everything to fit their naive 'filesystem hierarchy' (this completely fucks up a decent packager like Ruby Gems) * Breaking off features into separate packages whenever possible * Shipping ancient versions of software with a selection of patches picked specifically to introduce no features, just cherry-pick 'bug-fixes' * Shipping multiple versions of a runtime with mutually-exclusive depgraphs * FUCKING RELEASE FREEZES There's no goddamn reason for any non-system software to be frozen ever Ubuntu is making a decent stab at unfucking all this (at least on their turf) with PPAs: https://help.launchpad.net/Packaging/PPA https://help.launchpad.net/Packaging/PPA
- swolchok 17y ago
  There's no goddamn reason for any non-system software to be frozen ever What about, I don't know, developers who release early and often without good test coverage? If you're putting your seal of approval on a bunch of software, you probably want to make sure that it works. This cannot be done instantaneously.
  - blasdel 17y ago
    That doesn't mean you should be shipping the version of Firefox released when you last did a freeze, whether that's 6 months or 3 years ago. Even worse, with the way the freeze cycle is done in practice, they need to stop all updates even for bleeding edge users for several months (Ubuntu) or 6-18 months (Debian). In a rolling release system you don't have to have a single imprimatur of package approval. At minimum everyone implements it with at least 'stable', 'new', and 'fucked' markers for packages, and you can go way further with multiple repos and overlay semantics.
    - 17y ago
vegai 17y ago
Or perhaps start with something simple, like Arch's 'pacman'...

Debian's 'synaptic'. Help and leverage it to other platforms, if needed. Less pain all around.

by ableal 17y ago

Debian's 'synaptic'. Help and leverage it to other platforms, if needed. Less pain all around.

I sincerely doubt porting that to other platforms would be very easy, but perhaps you and I have different definitions of "pain." :) Plus, you'd have to worry about minor-yet-annoying namespace issues (e.g., a Python package and a non-Python package sharing a name). Am I the only one not offended by the idea of package managers for each programming language? They always work better when they're tailored to the language.

viraptor 17y ago
There are cases when they don't work better. It happens when your non-python program requires something from python for scripting, or when a python module requires a 'classic' library. A global system is quite good in those cases. I'm not sure what you mean by the namespace issues. Everything that's installed as a python package in debian is prefixed with "python-"...
ableal 17y ago
About the porting and the pain: I believe the hard parts are defining the metadata, and refining the actual program logic. In my experience over the last decade, 'synaptic' has been the most trouble-free system to use. I think it would be less work to clone/port the needed logic bits to Windows/whatever, and share most of the metadata defined for Debian/Ubuntu/etc, instead of redoing (and debugging) everything from scratch.
lucumo 17y ago
> Am I the only one not offended by the idea of package managers for each programming language? Learning multiple tools to do a similar job is a bit of a nuisance. If you know one tool, you can learn its details over time. That's much harder with multiple tools. Does tool X remove configuration files when uninstalling? Can it even uninstall? Do I need to update some configuration files manually? There's also the part where you sometimes need integration with packages from other package manager systems. System libraries (libcurl, etc.), header files if it gets compiled at install time, make, a compiler, etc. But since the problem is getting solved by multiple tools already (cpan, pear, apt, yum, just plain ./configure+make, etc.), maybe we should work more on integrating those package managers and less on replacing the others. It seems unlikely to happen with so many incompatible personal preferences around...

blasdel 17y ago

Please god no. Apt itself is barely good enough to handle libraries written in C, much less a dynamic language with multiple potentially-incompatible runtimes, and Debian's policies are dead set against making anything remotely wholesome: * As an author, affected middlemen have a stranglehold on easy distribution * License wankery (fuck debian-legal) * Teenagers randomly patching upstream software without review * Shipping non-standard configurations, often with features randomly disabled * Rearranging everything to fit their naive 'filesystem hierarchy' (this completely fucks up a decent packager like Ruby Gems) * Breaking off features into separate packages whenever possible * Shipping ancient versions of software with a selection of patches picked specifically to introduce no features, just cherry-pick 'bug-fixes' * Shipping multiple versions of a runtime with mutually-exclusive depgraphs * FUCKING RELEASE FREEZES There's no goddamn reason for any non-system software to be frozen ever Ubuntu is making a decent stab at unfucking all this (at least on their turf) with PPAs: https://help.launchpad.net/Packaging/PPA https://help.launchpad.net/Packaging/PPA

swolchok 17y ago
There's no goddamn reason for any non-system software to be frozen ever What about, I don't know, developers who release early and often without good test coverage? If you're putting your seal of approval on a bunch of software, you probably want to make sure that it works. This cannot be done instantaneously.
- blasdel 17y ago
  That doesn't mean you should be shipping the version of Firefox released when you last did a freeze, whether that's 6 months or 3 years ago. Even worse, with the way the freeze cycle is done in practice, they need to stop all updates even for bleeding edge users for several months (Ubuntu) or 6-18 months (Debian). In a rolling release system you don't have to have a single imprimatur of package approval. At minimum everyone implements it with at least 'stable', 'new', and 'fucked' markers for packages, and you can go way further with multiple repos and overlay semantics.
  - 17y ago

vegai 17y ago

Or perhaps start with something simple, like Arch's 'pacman'...