4 ms·

Last time I looked at this, they punted on interoperability with the system package manager. Are they likely to ever care about this, or is it just for people w

Last time I looked at this, they punted on interoperability with the system package manager. Are they likely to ever care about this, or is it just for people who aren't appalled at the thought of polluting individual machines with random libraries whose interdependencies are invisible in the dpkg or rpm database?

bkudria 16y ago
This sort of "integration" is enormously difficult. In fact, it's even ill-defined. I challenge you to design a useful system that works, but is general enough to integrate both dpkg and rpm.
- jwhitlark 16y ago
  Puppet. I'm increasingly convinced that a multilevel system is required to solve this type of problem.
  - regularfry 16y ago
    I agree. I think we need a protocol which is both package manager (dpkg, rpm) and environment (emacs, python, ruby) agnostic, with plugins to handle the specific cases. I think the starting point should be an RVM/perlbrew-alike for each environment; that'll keep the environment developers and those who like to be on the bleeding-edge happy. Then plugins to handle {gem,elpa,pip,...} -> (sufficiently general intermediate format) -> {deb,rpm,msi,...}, and we're done. Seemples.
jrockway 16y ago
It's like this for anywhere where you don't need to compile anything. Perl is an example; Debian depends on Perl internally, so you really don't want to depend on it as a programmer because it's going to change according to Debian's needs. If you fuck up @INC by installing stuff in there, then you run the risk of breaking your operating system. So most Perl programmers on Debian use some combination of local::lib or perlbrew and just have a Perl-install-per-app. Emacs is a little different in that nothing is going to break the system; but if user A wants Emacs extension A and user B wants Emacs extension B, but they conflict (say, by depending on different versions of foo.el), then the system can't resolve that. By delegating the management of third-party extensions to the user, this conflict is avoided. My personal policy is that I only use OS packages for things I don't care about. I mostly use emacs, conkeror, rxvt-unicode and xmonad, so all those packages are intalled from git/darcs into my homedir so that I can easily hack on them. Stuff like "ls" I let the OS handle, because the stock "ls"'s featureset meets my needs. Anyway, package systems are nice from an organization perspective, and there's no reason not to submit your favorite Emacs extensions to Debian. But it's not a perfect answer to every situation.
technomancy 16y ago
There are many reasons dpkg is inappropriate: 0) It shouldn't require sudo access. 1) It must support multiple versions installed side-by-side for different users. 2) dpkg only supports a fraction of the potential users. package.el supports them all by virtue of inclusion in Emacs.

bkudria 16y ago

This sort of "integration" is enormously difficult. In fact, it's even ill-defined. I challenge you to design a useful system that works, but is general enough to integrate both dpkg and rpm.

jwhitlark 16y ago
Puppet. I'm increasingly convinced that a multilevel system is required to solve this type of problem.
- regularfry 16y ago
  I agree. I think we need a protocol which is both package manager (dpkg, rpm) and environment (emacs, python, ruby) agnostic, with plugins to handle the specific cases. I think the starting point should be an RVM/perlbrew-alike for each environment; that'll keep the environment developers and those who like to be on the bleeding-edge happy. Then plugins to handle {gem,elpa,pip,...} -> (sufficiently general intermediate format) -> {deb,rpm,msi,...}, and we're done. Seemples.

jrockway 16y ago

It's like this for anywhere where you don't need to compile anything. Perl is an example; Debian depends on Perl internally, so you really don't want to depend on it as a programmer because it's going to change according to Debian's needs. If you fuck up @INC by installing stuff in there, then you run the risk of breaking your operating system. So most Perl programmers on Debian use some combination of local::lib or perlbrew and just have a Perl-install-per-app. Emacs is a little different in that nothing is going to break the system; but if user A wants Emacs extension A and user B wants Emacs extension B, but they conflict (say, by depending on different versions of foo.el), then the system can't resolve that. By delegating the management of third-party extensions to the user, this conflict is avoided. My personal policy is that I only use OS packages for things I don't care about. I mostly use emacs, conkeror, rxvt-unicode and xmonad, so all those packages are intalled from git/darcs into my homedir so that I can easily hack on them. Stuff like "ls" I let the OS handle, because the stock "ls"'s featureset meets my needs. Anyway, package systems are nice from an organization perspective, and there's no reason not to submit your favorite Emacs extensions to Debian. But it's not a perfect answer to every situation.

technomancy 16y ago

There are many reasons dpkg is inappropriate: 0) It shouldn't require sudo access. 1) It must support multiple versions installed side-by-side for different users. 2) dpkg only supports a fraction of the potential users. package.el supports them all by virtue of inclusion in Emacs.