5 ms·

Why the heck are you writing a custom installer like this? One possible example: User specific installs. Interaction with the system package manager requires r

Why the heck are you writing a custom installer like this? One possible example: User specific installs. Interaction with the system package manager requires root rights, and isn't something that is a good fit for something like, say, RVM or rbenv. If I'm a nonprivileged user on someone else's general purpose system, I shouldn't have to bug the administrator to install something useful to me.

Filligree 11y ago
Nix solves this problem neatly. Not saying that's answering your question, since Nix is woefully underused, but it's something to look at.
- codemac 11y ago
  Yeah I've been using arch for my "root" and guix for my users and it's a wonderland of excellence. If you're interested in nix / guix, installing them and using them without the whole OS is a great way to get started.
peterwwillis 11y ago
All package managers allow user-specific installs.
- Karunamon 11y ago
  As a special case, sure. http://askubuntu.com/questions/339/how-can-i-install-a-package-without-root-access http://askubuntu.com/questions/339/how-can-i-install-a-packa... http://askubuntu.com/questions/28619/how-do-i-install-an-application-by-deb-file-for-a-single-user-only http://askubuntu.com/questions/28619/how-do-i-install-an-app... But if you're going to extract deb files, why not just extract tarballs? Or better yet, just curl|bash? :)
  - peterwwillis 11y ago
    There's lots of reasons to use packages. Verification, versioning, bug tracking, offline use, system-install, user-install, dependency tracking, rollback, sanity checking, custom install steps, and being tested and certified for a particular repository and software branch, among others. But, you know, if you just want to install something and not know what it is, what it does, how to fix it or remove it, much less whether it's even the software you expected, curl|bash is okay.
    - Karunamon 11y ago
      We're talking about extracting packages in a one-off, unsupported configuration that literally nobody does, not using them as intended, so 90% of those things you mentioned are off the table.
      - peterwwillis 11y ago
        What is off the table, exactly? You asked why you would extract a deb instead of extracting a tarball or curl|bash, right? Because the deb is verifiable, because the deb can be inspected, because the deb is versioned, because the deb can be bug-reported, because the deb has dependency info, because you know what the deb was built for and supports, because the deb has clear scripts which tell you how to install and uninstall it, because it can be unpacked offline, etc. Maybe you don't care about any of this. That is fine. I'm just telling you what the Deb gives you that a tarball or curl|bash won't.
        Karunamon 11y ago
        * Just about every .tgz I've ever downloaded had instructions on the downloading page to verify its signature * I can inspect a .tgz easier than a .deb (tar -tzf) * More often than not, the tgz version is in its filename (foobar.1.3.0-24.amd64.tgz) * With that info, I can bug report it * Fair 'nuff on depdencies * I know what the tgz was built for and supports by either the download page or the filename * Just about every tgz package I've ever downloaded included a Makefile that handled installation and uninstallation * Offline unpacking is the only way to handle tgz's Literally the only benefit to offline unpacking a .deb vs offline unpacking a .tgz is that the former includes a CONTROL file that lists dependencies in it.
- daxelrod 11y ago
  How would I install a package from one of the repositories as a non-root user for RPM or dpkg? I am not aware of any way to do this within either of those package managers.
  - peterwwillis 11y ago
    You could use google for five minutes and find the answer. RedHat/Fedora have it as part of their guide on using RPM. (Hint: it involves making your own .rpmrc file) Dpkg supports something similar but I forget when I last used it. Worst case you can just unpack the files into a local directory, add to your PATH and run it.
    - daxelrod 11y ago
      I asked this only after googling, and having done previous research. The best I was able to find for RPM is https://www.redhat.com/archives/rpm-list/2001-December/msg00077.html https://www.redhat.com/archives/rpm-list/2001-December/msg00... , which involves creating your own RPM database in your user directory, and using --prefix. Unfortunately, --prefix requires an RPM to have been built with relocatability http://www.rpm.org/max-rpm/s1-rpm-reloc-building-relocatable.html http://www.rpm.org/max-rpm/s1-rpm-reloc-building-relocatable... in mind, and my experience is that most RPMs I've found from RedHat, EPEL, and Fedora aren't actually relocatable. Further many of them depend upon other root-specific things like creating new users, editing init files, chowning, etc. Of course, with this approach, you also need to create a dummy package to provide dependencies for all of the root-installed things on the system, and keep it up to date yourself. I looked through https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html-single/RPM_Guide/ https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentat... at your suggestion, but was unable to find the section you're talking about. Perhaps I overlooked it? I'll also note that yum requires root unless you're willing to make substantial modifications to its source code, a process that I started but was never able to finish. This is outside of the scope of what I asked, however. I'm less familiar with dpkg, but everything I've found so far simply suggests going around the package manager and instead unpacking the package and dealing with it manually.

Filligree 11y ago

Nix solves this problem neatly. Not saying that's answering your question, since Nix is woefully underused, but it's something to look at.

codemac 11y ago
Yeah I've been using arch for my "root" and guix for my users and it's a wonderland of excellence. If you're interested in nix / guix, installing them and using them without the whole OS is a great way to get started.

peterwwillis 11y ago

All package managers allow user-specific installs.

Karunamon 11y ago
As a special case, sure. http://askubuntu.com/questions/339/how-can-i-install-a-package-without-root-access http://askubuntu.com/questions/339/how-can-i-install-a-packa... http://askubuntu.com/questions/28619/how-do-i-install-an-application-by-deb-file-for-a-single-user-only http://askubuntu.com/questions/28619/how-do-i-install-an-app... But if you're going to extract deb files, why not just extract tarballs? Or better yet, just curl|bash? :)
- peterwwillis 11y ago
  There's lots of reasons to use packages. Verification, versioning, bug tracking, offline use, system-install, user-install, dependency tracking, rollback, sanity checking, custom install steps, and being tested and certified for a particular repository and software branch, among others. But, you know, if you just want to install something and not know what it is, what it does, how to fix it or remove it, much less whether it's even the software you expected, curl|bash is okay.
  - Karunamon 11y ago
    We're talking about extracting packages in a one-off, unsupported configuration that literally nobody does, not using them as intended, so 90% of those things you mentioned are off the table.
    - peterwwillis 11y ago
      What is off the table, exactly? You asked why you would extract a deb instead of extracting a tarball or curl|bash, right? Because the deb is verifiable, because the deb can be inspected, because the deb is versioned, because the deb can be bug-reported, because the deb has dependency info, because you know what the deb was built for and supports, because the deb has clear scripts which tell you how to install and uninstall it, because it can be unpacked offline, etc. Maybe you don't care about any of this. That is fine. I'm just telling you what the Deb gives you that a tarball or curl|bash won't.
      - Karunamon 11y ago
        * Just about every .tgz I've ever downloaded had instructions on the downloading page to verify its signature * I can inspect a .tgz easier than a .deb (tar -tzf) * More often than not, the tgz version is in its filename (foobar.1.3.0-24.amd64.tgz) * With that info, I can bug report it * Fair 'nuff on depdencies * I know what the tgz was built for and supports by either the download page or the filename * Just about every tgz package I've ever downloaded included a Makefile that handled installation and uninstallation * Offline unpacking is the only way to handle tgz's Literally the only benefit to offline unpacking a .deb vs offline unpacking a .tgz is that the former includes a CONTROL file that lists dependencies in it.
daxelrod 11y ago
How would I install a package from one of the repositories as a non-root user for RPM or dpkg? I am not aware of any way to do this within either of those package managers.
- peterwwillis 11y ago
  You could use google for five minutes and find the answer. RedHat/Fedora have it as part of their guide on using RPM. (Hint: it involves making your own .rpmrc file) Dpkg supports something similar but I forget when I last used it. Worst case you can just unpack the files into a local directory, add to your PATH and run it.
  - daxelrod 11y ago
    I asked this only after googling, and having done previous research. The best I was able to find for RPM is https://www.redhat.com/archives/rpm-list/2001-December/msg00077.html https://www.redhat.com/archives/rpm-list/2001-December/msg00... , which involves creating your own RPM database in your user directory, and using --prefix. Unfortunately, --prefix requires an RPM to have been built with relocatability http://www.rpm.org/max-rpm/s1-rpm-reloc-building-relocatable.html http://www.rpm.org/max-rpm/s1-rpm-reloc-building-relocatable... in mind, and my experience is that most RPMs I've found from RedHat, EPEL, and Fedora aren't actually relocatable. Further many of them depend upon other root-specific things like creating new users, editing init files, chowning, etc. Of course, with this approach, you also need to create a dummy package to provide dependencies for all of the root-installed things on the system, and keep it up to date yourself. I looked through https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html-single/RPM_Guide/ https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentat... at your suggestion, but was unable to find the section you're talking about. Perhaps I overlooked it? I'll also note that yum requires root unless you're willing to make substantial modifications to its source code, a process that I started but was never able to finish. This is outside of the scope of what I asked, however. I'm less familiar with dpkg, but everything I've found so far simply suggests going around the package manager and instead unpacking the package and dealing with it manually.