5 ms·

RubyGems only allows the installation of binary files to bin. Lots of binary files should go into sbin. This is a serious limitation with packaging.

tptacek 16y ago
If the author of the package is fine with the binaries going into bin, why do you care?
- jamtur01 16y ago
  So I am going to suggest you're a developer. I am, amongst other things, a packager. Lots of platforme mandate that certain types of binaries go in certain places. This isntpossible with gems. I find this very frustrating for the gems I maintain - including Puppet for example.
  - tptacek 16y ago
    If FHS religion means you can't put something in bin(7) if it's an admin-only tool, and the author of that tool built it in a way that only allows it to be installed in bin(7) and not sbin(7), then don't package the tool. The "alter the tool so it fits with our doctrines" approach hasn't worked. Again, this isn't Ruby saying "Jeb's network configuration script must go in bin(7) even though he wants it to go in sbin(7)". This is "every Ruby developer writes tools that go in some variant of bin(7)", and Debian not liking that. Which, fine. Don't like it. Just don't package them.
    - jamtur01 16y ago
      Don't package them isn't a solution. It's sticking your head in the sand. Again and again in the Ruby world I see the "it works for us web developers on the x number of hosts we run". The people who use Ruby for stand-alone applications across multiple hosts are largely ignored. I'd love to see more Ruby out there - ignoring the needs of people other than developers guarantees that'll never happen. Big shops and sys admins who run non-web applications (and even those who run Ruby/Rails web applications and find the RubyGems/Passenger/Rails/Ruby/etc/etc intra/inter version interoperability failures baffling) will look at it as a manual, difficult to package solution and find other tools written in other languages. That'll be a real shame.
      - tptacek 16y ago
        You'd like the Ruby world to be different from what it is, and more like the Debian world. So you broke Ruby. Yes, I get it.
    - adamzochowski 16y ago
      isn't the definition /bin system binaries for all users /sbin system binaries for root /usr/bin distro binaries for all users /usr/sbin distro binaries for root /usr/local/bin binaries managed by repository, but not by distro for all users /usr/local/sbin binaries managed by repository, but not by distro for all root /opt/bin/ user compiled and installed binaries for all users /opt/sbin/ root compiled and installed binaries for root purposes more or less? I would expect GEMs to follow behaviour?
  - fanf2 16y ago
    Gratuitous differences between Debian and the upstream installation layout are REALLY ANNOYING. It breaks all sorts of online documentation and means Debian users have to deal with unnecessary compatibility bugs.
FooBarWidget 16y ago
Is there any reason why you care so much about bin-vs-sbin that would make it such a dealbreaker, other than FHS ideology? Most people I know just care whether the command works, i.e. whether it's in $PATH.
- jamtur01 16y ago
  We care because our customers - big, enterprise shops with thousands of hosts they manage with packages - care.
  - tptacek 16y ago
    They care that a specific random Ruby utility was by design installed in bin(7) and thus require that Debian specifically modifies the package so that it goes in sbin(7)? I call shenanigans.
    - jamtur01 16y ago
      You're missing my point - it's a RubyGems issue not a Debian one. Standards matter.
      - halostatue 16y ago
        Standards matter, but differ between platforms and even distributions. Ruby is not—and should not be—beholden to any single distro's particular oddities. Adaptable, yes; broken on other platforms because of, no.
        adamzochowski 16y ago
        I think the idea is that on every OS you talk the talk. Windows uses backslashes instead of slashes. etc. You meld application to OS, not the other way around. GEMs on Debian should follow Debian ideology, much like on windows they follow windows way.

tptacek 16y ago

If the author of the package is fine with the binaries going into bin, why do you care?

jamtur01 16y ago
So I am going to suggest you're a developer. I am, amongst other things, a packager. Lots of platforme mandate that certain types of binaries go in certain places. This isntpossible with gems. I find this very frustrating for the gems I maintain - including Puppet for example.
- tptacek 16y ago
  If FHS religion means you can't put something in bin(7) if it's an admin-only tool, and the author of that tool built it in a way that only allows it to be installed in bin(7) and not sbin(7), then don't package the tool. The "alter the tool so it fits with our doctrines" approach hasn't worked. Again, this isn't Ruby saying "Jeb's network configuration script must go in bin(7) even though he wants it to go in sbin(7)". This is "every Ruby developer writes tools that go in some variant of bin(7)", and Debian not liking that. Which, fine. Don't like it. Just don't package them.
  - jamtur01 16y ago
    Don't package them isn't a solution. It's sticking your head in the sand. Again and again in the Ruby world I see the "it works for us web developers on the x number of hosts we run". The people who use Ruby for stand-alone applications across multiple hosts are largely ignored. I'd love to see more Ruby out there - ignoring the needs of people other than developers guarantees that'll never happen. Big shops and sys admins who run non-web applications (and even those who run Ruby/Rails web applications and find the RubyGems/Passenger/Rails/Ruby/etc/etc intra/inter version interoperability failures baffling) will look at it as a manual, difficult to package solution and find other tools written in other languages. That'll be a real shame.
    - tptacek 16y ago
      You'd like the Ruby world to be different from what it is, and more like the Debian world. So you broke Ruby. Yes, I get it.
  - adamzochowski 16y ago
    isn't the definition /bin system binaries for all users /sbin system binaries for root /usr/bin distro binaries for all users /usr/sbin distro binaries for root /usr/local/bin binaries managed by repository, but not by distro for all users /usr/local/sbin binaries managed by repository, but not by distro for all root /opt/bin/ user compiled and installed binaries for all users /opt/sbin/ root compiled and installed binaries for root purposes more or less? I would expect GEMs to follow behaviour?
- fanf2 16y ago
  Gratuitous differences between Debian and the upstream installation layout are REALLY ANNOYING. It breaks all sorts of online documentation and means Debian users have to deal with unnecessary compatibility bugs.

FooBarWidget 16y ago

Is there any reason why you care so much about bin-vs-sbin that would make it such a dealbreaker, other than FHS ideology? Most people I know just care whether the command works, i.e. whether it's in $PATH.

jamtur01 16y ago
We care because our customers - big, enterprise shops with thousands of hosts they manage with packages - care.
- tptacek 16y ago
  They care that a specific random Ruby utility was by design installed in bin(7) and thus require that Debian specifically modifies the package so that it goes in sbin(7)? I call shenanigans.
  - jamtur01 16y ago
    You're missing my point - it's a RubyGems issue not a Debian one. Standards matter.
    - halostatue 16y ago
      Standards matter, but differ between platforms and even distributions. Ruby is not—and should not be—beholden to any single distro's particular oddities. Adaptable, yes; broken on other platforms because of, no.
      - adamzochowski 16y ago
        I think the idea is that on every OS you talk the talk. Windows uses backslashes instead of slashes. etc. You meld application to OS, not the other way around. GEMs on Debian should follow Debian ideology, much like on windows they follow windows way.