7 ms·

I recently blogged about the Linux world needing something like this. http://leto.electropoiesis.org/propaganda/plugins-and-packages-and-extensions-and-bundles

I recently blogged about the Linux world needing something like this. http://leto.electropoiesis.org/propaganda/plugins-and-packages-and-extensions-and-bundles-oh-my/ http://leto.electropoiesis.org/propaganda/plugins-and-packag... I hate having to individually update my Wordpress install, my Rubies, my system packages, my IDE (be it Eclipse or Android Studio), a separate TeXLive install from the OS packages, even Vim now has its own package management with Pathogen... There must be some way to _unify_ this proliferation of software update mechanisms. edit: It would be ironic in the extreme if Windows of all platforms manages to get this out the gate before the Linux community considering how awesome stuff like apt-get, yum, and emerge are... Oh well, just goes to show that open-source giveth with the one hand and taketh with the other.

Sir_Substance 12y ago
https://xkcd.com/927/ https://xkcd.com/927/
- igravious 12y ago
  So cynical. But unfortunately, so true.
- Digit-Al 12y ago
  Ha! That's exactly the first thought I had. I guessed someone would beat me to it :-)
lqdc13 12y ago
They should just all be in PPAs on Ubuntu.
brusch64 12y ago
Have you ever tried ninite (https://ninite.com/ https://ninite.com/) ? Not perfect at all - but at least it works for some of the freeware utilities / programs I'm using on my windows PC. Simply run the generated exe to install the program. Run it later to update the program.
- igravious 12y ago
  Looks cool, but I meant for Linux specifically. Apple and Microsoft have ultimate control over their ecosystems when it comes down to brass tacks.
politician 12y ago
Give it about 6 months and someone will announce a container-based package manager.
- igravious 12y ago
  Hum, you could be right. I tried to install Discourse from source a while back on CentOS and gave up. A while later I tried the container method (Docker I believe) and bingo. So much magic going on under the hood though, dunno how I feel about it...
  - sz4kerto 12y ago
    This kind of reminds me of just statically linking everything. We have not done that because it is a waste of resources but containers are all right then. :) (OK, I'm aware of the differences, but I don't see containers as a salvation for client-side deployment.)
- nfoz 12y ago
  https://developer.ubuntu.com/en/snappy/tutorials/using-snappy/ https://developer.ubuntu.com/en/snappy/tutorials/using-snapp... I was informed about this just this morning.
davexunit 12y ago
>There must be some way to _unify_ this proliferation of software update mechanisms. https://gnu.org/s/guix https://gnu.org/s/guix https://nixos.org https://nixos.org
- cwyers 12y ago
  Unify != replace. Guix/Nix don't integrate multiple package managers, it just is Another Package Manager.
  - davexunit 12y ago
    They are the only package managers I know of capable of unifying package management with a single set of tools. Unifying multiple distinct package managers is a fool's errand.
    - zokier 12y ago
      > Unifying multiple distinct package managers is a fool's errand I disagree. Why do you think that is the case?
      - davexunit 12y ago
        Different package managers make different design decisions that make them incompatible with each other without sacrifice. Guix/Nix focus heavily on reproducibility and not relying on any third party binaries. These features would have to be thrown away if it unified pip, npm, etc. because they make no such guarantees. Every package manager works different, and trying to accomadate all of them with a unifying tool will require a lot of time wasted writing interfaces between them all. I don't see a way to do it without lowering the feature set to the least common denominator and settling with that. The real solution is to elevate our system package managers to the point of handling the important use cases that currently only language package managers provide, such as virtualenv/Bundler style management (i.e. installing packages somewhere besides /). Nix/Guix accomodate all such use cases, which is why I promote them.
vezzy-fnord 12y ago
There must be some way to _unify_ this proliferation of software update mechanisms. There's PackageKit, though that's mostly used for creating those graphical software center/app store types of applications.
- igravious 12y ago
  Interesting approach. Link here: http://www.freedesktop.org/software/PackageKit/pk-intro.html http://www.freedesktop.org/software/PackageKit/pk-intro.html
TazeTSchnitzel 12y ago
> PHP Pear Actually, Composer is what's usually used these days. Composer is per-project (like npm), though, so there's no point unifying it into a global package manager.
- igravious 12y ago
  See, I didn't even know that about Pear and Composer. And I totally forgot to mention npm and bower from the javascript world, both of which I use.
pjc50 12y ago
It's a disaster. The proper way to do it is distro packages, but for some reason every language, framework, ecosystem and individual developer wants to reinvent this particular wheel. I really don't understand why.
- wldcordeiro 12y ago
  Distro packages move slower than people would like so they create their own solution.
  - vetinari 12y ago
    You know, it is still simpler to make your own deb or rpm, than entirely different package system. It is more of a case, that these different package systems were introduced on platform that lacks native one. Then, by combination of laziness/not wanting to build another package and recycling the already built binaries, they got a traction on linux systems too. And there is a reason, why distro packages move slower - people having that deployed in production do not like breaking changes. If you want bleeding edge packages, use bleeding edge repos.
- Goladus 12y ago
  It's because individual tools usually don't want to be tied to assumptions made by one particular distro. I actively avoid using distro packages for 3rd party development libraries and such, especially when a good tool for accessing upstream sources (eg pip) is available. I use packages for certain tools and platforms, and libraries if I feel the library is really something I want to be a standard part of the system environment. For example, I am more likely to use the distro package of a python library (if available) if I'm planning to use the library for a system administration task than if I am planning to use it for application development. I'm also likely to use distro packages for things like apache, nginx, postfix, unless I have some case-specific reason not to.
  - jfroma 12y ago
    One technical reason is that I might use two different versions of the same library in different projects and apt-get only allows me to have one at the time. I think npm and gem are brilliant on this regard. Best of both words: docker. I consider docker an application packager.
Goladus 12y ago
> There must be some way to _unify_ this proliferation of software update mechanisms. There are many ways. The problem is there are many different environments who all use different methods for different reasons. To a solo developer with personal control over the entire stack, the Operating System is merely one more tool in the toolbox. That dev can pick any distro he wants and then install and configure anything he wants(as root). To a postdoc researcher in a lab using the University's shared compute cluster, leveraging the OS might not be such an obvious and easy choice. Then of course there is the whole issue that Wordpress, ruby, system software, and IDEs are all developed by very different groups of people. But back to your question: configuration management tools can help with this problem. They do require some end-user investment at this stage, in no small part due to the reasons I identified above (there's not yet an ideal default that works for everyone). Generally, configuration management tools encourage you to declare your software, modules, packages, requirements in an abstraction layer and then have the config management tool handle the messy details of whether to use apt or yum or gems. The catch right now is that you will typically have to do handle those decisions (to some extent) yourself. Ansible: http://docs.ansible.com/gem_module.html http://docs.ansible.com/gem_module.html http://docs.ansible.com/apt_module.html http://docs.ansible.com/apt_module.html http://docs.ansible.com/yum_module.html http://docs.ansible.com/yum_module.html Puppet: https://docs.puppetlabs.com/references/latest/type.html#package-providers https://docs.puppetlabs.com/references/latest/type.html#pack... Chef: https://docs.chef.io/chef/resources.html#gem-package https://docs.chef.io/chef/resources.html#gem-package https://docs.chef.io/chef/resources.html#apt-package https://docs.chef.io/chef/resources.html#apt-package https://docs.chef.io/chef/resources.html#yum-package https://docs.chef.io/chef/resources.html#yum-package
- igravious 12y ago
  Aha! Lightbulb moment. I thought that Puppet and co. (chef and so on) were about pure configuration across multiple machines. I didn't realise they were about deployment as well. In that case I guess the problem is sort of solved but then I need to start thinking a layer higher than I have been. It would be nice if the solution to this proliferation still allowed me to think at the level of [synaptic/apt-get/dpkg] on Debian/Ubuntu/... or [yum/rpm] on Redhat/CentOS/Suse/... and so on. Do you think this is unreasonable of me?
eliaspro 12y ago
There's no need to unify the installation of those domain-specific package managers - those packages just need to provide proper machine-readable metadata to make it possible to build distribution packages out of them so there's no need to create another 10 package-datasilos outside of the system's package-manager's control. The very idea of placing dependencies in a local location (or even worse in a global location but not controlled by the system package-manager) is so rotten from the core - it simply deserves to die. What was once supposed to be a tool for developers to have easy access to dependencies has now crept into the area of operation and deploying uncontrollable stuff (Docker containers, 3rd party package managers, statically linked applications, manually built packages, …) into production systems has become the norm.

Sir_Substance 12y ago

https://xkcd.com/927/ https://xkcd.com/927/

igravious 12y ago
So cynical. But unfortunately, so true.
Digit-Al 12y ago
Ha! That's exactly the first thought I had. I guessed someone would beat me to it :-)

lqdc13 12y ago

They should just all be in PPAs on Ubuntu.

brusch64 12y ago

Have you ever tried ninite (https://ninite.com/ https://ninite.com/) ? Not perfect at all - but at least it works for some of the freeware utilities / programs I'm using on my windows PC. Simply run the generated exe to install the program. Run it later to update the program.

igravious 12y ago
Looks cool, but I meant for Linux specifically. Apple and Microsoft have ultimate control over their ecosystems when it comes down to brass tacks.

politician 12y ago

Give it about 6 months and someone will announce a container-based package manager.

igravious 12y ago
Hum, you could be right. I tried to install Discourse from source a while back on CentOS and gave up. A while later I tried the container method (Docker I believe) and bingo. So much magic going on under the hood though, dunno how I feel about it...
- sz4kerto 12y ago
  This kind of reminds me of just statically linking everything. We have not done that because it is a waste of resources but containers are all right then. :) (OK, I'm aware of the differences, but I don't see containers as a salvation for client-side deployment.)
nfoz 12y ago
https://developer.ubuntu.com/en/snappy/tutorials/using-snappy/ https://developer.ubuntu.com/en/snappy/tutorials/using-snapp... I was informed about this just this morning.

davexunit 12y ago

>There must be some way to _unify_ this proliferation of software update mechanisms. https://gnu.org/s/guix https://gnu.org/s/guix https://nixos.org https://nixos.org

cwyers 12y ago
Unify != replace. Guix/Nix don't integrate multiple package managers, it just is Another Package Manager.
- davexunit 12y ago
  They are the only package managers I know of capable of unifying package management with a single set of tools. Unifying multiple distinct package managers is a fool's errand.
  - zokier 12y ago
    > Unifying multiple distinct package managers is a fool's errand I disagree. Why do you think that is the case?
    - davexunit 12y ago
      Different package managers make different design decisions that make them incompatible with each other without sacrifice. Guix/Nix focus heavily on reproducibility and not relying on any third party binaries. These features would have to be thrown away if it unified pip, npm, etc. because they make no such guarantees. Every package manager works different, and trying to accomadate all of them with a unifying tool will require a lot of time wasted writing interfaces between them all. I don't see a way to do it without lowering the feature set to the least common denominator and settling with that. The real solution is to elevate our system package managers to the point of handling the important use cases that currently only language package managers provide, such as virtualenv/Bundler style management (i.e. installing packages somewhere besides /). Nix/Guix accomodate all such use cases, which is why I promote them.

vezzy-fnord 12y ago

There must be some way to _unify_ this proliferation of software update mechanisms. There's PackageKit, though that's mostly used for creating those graphical software center/app store types of applications.

igravious 12y ago
Interesting approach. Link here: http://www.freedesktop.org/software/PackageKit/pk-intro.html http://www.freedesktop.org/software/PackageKit/pk-intro.html

TazeTSchnitzel 12y ago

> PHP Pear Actually, Composer is what's usually used these days. Composer is per-project (like npm), though, so there's no point unifying it into a global package manager.

igravious 12y ago
See, I didn't even know that about Pear and Composer. And I totally forgot to mention npm and bower from the javascript world, both of which I use.

pjc50 12y ago

It's a disaster. The proper way to do it is distro packages, but for some reason every language, framework, ecosystem and individual developer wants to reinvent this particular wheel. I really don't understand why.

wldcordeiro 12y ago
Distro packages move slower than people would like so they create their own solution.
- vetinari 12y ago
  You know, it is still simpler to make your own deb or rpm, than entirely different package system. It is more of a case, that these different package systems were introduced on platform that lacks native one. Then, by combination of laziness/not wanting to build another package and recycling the already built binaries, they got a traction on linux systems too. And there is a reason, why distro packages move slower - people having that deployed in production do not like breaking changes. If you want bleeding edge packages, use bleeding edge repos.
Goladus 12y ago
It's because individual tools usually don't want to be tied to assumptions made by one particular distro. I actively avoid using distro packages for 3rd party development libraries and such, especially when a good tool for accessing upstream sources (eg pip) is available. I use packages for certain tools and platforms, and libraries if I feel the library is really something I want to be a standard part of the system environment. For example, I am more likely to use the distro package of a python library (if available) if I'm planning to use the library for a system administration task than if I am planning to use it for application development. I'm also likely to use distro packages for things like apache, nginx, postfix, unless I have some case-specific reason not to.
- jfroma 12y ago
  One technical reason is that I might use two different versions of the same library in different projects and apt-get only allows me to have one at the time. I think npm and gem are brilliant on this regard. Best of both words: docker. I consider docker an application packager.

Goladus 12y ago

> There must be some way to _unify_ this proliferation of software update mechanisms. There are many ways. The problem is there are many different environments who all use different methods for different reasons. To a solo developer with personal control over the entire stack, the Operating System is merely one more tool in the toolbox. That dev can pick any distro he wants and then install and configure anything he wants(as root). To a postdoc researcher in a lab using the University's shared compute cluster, leveraging the OS might not be such an obvious and easy choice. Then of course there is the whole issue that Wordpress, ruby, system software, and IDEs are all developed by very different groups of people. But back to your question: configuration management tools can help with this problem. They do require some end-user investment at this stage, in no small part due to the reasons I identified above (there's not yet an ideal default that works for everyone). Generally, configuration management tools encourage you to declare your software, modules, packages, requirements in an abstraction layer and then have the config management tool handle the messy details of whether to use apt or yum or gems. The catch right now is that you will typically have to do handle those decisions (to some extent) yourself. Ansible: http://docs.ansible.com/gem_module.html http://docs.ansible.com/gem_module.html http://docs.ansible.com/apt_module.html http://docs.ansible.com/apt_module.html http://docs.ansible.com/yum_module.html http://docs.ansible.com/yum_module.html Puppet: https://docs.puppetlabs.com/references/latest/type.html#package-providers https://docs.puppetlabs.com/references/latest/type.html#pack... Chef: https://docs.chef.io/chef/resources.html#gem-package https://docs.chef.io/chef/resources.html#gem-package https://docs.chef.io/chef/resources.html#apt-package https://docs.chef.io/chef/resources.html#apt-package https://docs.chef.io/chef/resources.html#yum-package https://docs.chef.io/chef/resources.html#yum-package

igravious 12y ago
Aha! Lightbulb moment. I thought that Puppet and co. (chef and so on) were about pure configuration across multiple machines. I didn't realise they were about deployment as well. In that case I guess the problem is sort of solved but then I need to start thinking a layer higher than I have been. It would be nice if the solution to this proliferation still allowed me to think at the level of [synaptic/apt-get/dpkg] on Debian/Ubuntu/... or [yum/rpm] on Redhat/CentOS/Suse/... and so on. Do you think this is unreasonable of me?

eliaspro 12y ago

There's no need to unify the installation of those domain-specific package managers - those packages just need to provide proper machine-readable metadata to make it possible to build distribution packages out of them so there's no need to create another 10 package-datasilos outside of the system's package-manager's control. The very idea of placing dependencies in a local location (or even worse in a global location but not controlled by the system package-manager) is so rotten from the core - it simply deserves to die. What was once supposed to be a tool for developers to have easy access to dependencies has now crept into the area of operation and deploying uncontrollable stuff (Docker containers, 3rd party package managers, statically linked applications, manually built packages, …) into production systems has become the norm.