I used some confusing statements in my previous comment. I would also like to clarify some things.
1) Package installed with domain-specific manager like gem or pip becomes "debian" package at installation time. It can be removed and upgraded using either of the managers (with appropriate hooks/triggers ensuring that the process behaves properly). Dpkg would have all the proper meta-data about packages (like files, md5sums and so on). The only meta-data that would be partially missing is native dependencies that debianized packages of domain-specific packages sometimes have. 2) Packages with more than one version could be mangled into different packages inside debian. This is suboptimal but would work. It _probably_ will be hard to do generate proper virtual packages so that I can install libfoo-1.2.3 and still get libfoo1 and libfoo1.2 3) Packages that already have been debianized might need to conflict with the domain-specific packages. I can see a lot of potential issues here (domain specific package becomes many debian packages for example, slightly different names, debian-specific patches). This is a big topic for research. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/706603 Title: gem1.9.1 doens't install executables on PATH -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
