5 ms·

Upstream developers don’t have the time and bandwidth to set up packaging for all distros and versions. Improving defaults may be fine according to some. Remov

Upstream developers don’t have the time and bandwidth to set up packaging for all distros and versions. Improving defaults may be fine according to some. Removing major features advertised by the software due to political reasons is not fine. My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version). How is this “better integration with the philosophy”?

ranger_danger 2y ago
I think one of the potentially bigger things that doesn't yet exist is an easy way for non-developers to build their own packages with whatever options they want. By easy I mean a GUI tool that works across the majority of projects out there, and on any distro.
sangnoir 2y ago
> My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version) As a Debian stable devotee, this seems reasonable to me. If I wanted each package to bring along & manage its own dependencies, I'd use flatpaks. > How is this “better integration with the philosophy”? I'm guessing Bootstrap 3 wasn't yet in whatever release/channel your software was being packaged for? Can't you imagine any possible benefits of not shipping bootstrap v2 and Bootstrap v3? Or do you just disagree with the Debian unstable -> testing -> stable philosophy? Dependency juggling is just one of the issues distro package maintainers have to wrangle with, that upstream maintainers typically don't care about - an upstream project can declare "this version requires the latest glibc", but distro packagers may have to patch around that because the latest version of glibc hasn't been through testing.
- Kwpolska 2y ago
  We ship a copy of bootstrap within our data files. They could just leave it as-is and have it working. Bootstrap is a CSS/JS library, there is no global /usr/lib to be concerned about.
  - sangnoir 2y ago
    Most of HN who've been around know what Bootstrap is (rip, old Twitter). The same rules apply whether your package dependencies are .css, .js or .so
  - cassianoleal 2y ago
    > because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package > there is no global /usr/lib to be concerned about Aside from possibly the path being different, which is of no concern, how can the 2 above sentences reconcile with each other?
    - Kwpolska 2y ago
      It is trivial to make the Bootstrap 3 global package install into a different folder than Bootstrap 2. It isn’t so trivial for shared libraries without different sonames, for example.

ranger_danger 2y ago

I think one of the potentially bigger things that doesn't yet exist is an easy way for non-developers to build their own packages with whatever options they want. By easy I mean a GUI tool that works across the majority of projects out there, and on any distro.

sangnoir 2y ago

> My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version) As a Debian stable devotee, this seems reasonable to me. If I wanted each package to bring along & manage its own dependencies, I'd use flatpaks. > How is this “better integration with the philosophy”? I'm guessing Bootstrap 3 wasn't yet in whatever release/channel your software was being packaged for? Can't you imagine any possible benefits of not shipping bootstrap v2 and Bootstrap v3? Or do you just disagree with the Debian unstable -> testing -> stable philosophy? Dependency juggling is just one of the issues distro package maintainers have to wrangle with, that upstream maintainers typically don't care about - an upstream project can declare "this version requires the latest glibc", but distro packagers may have to patch around that because the latest version of glibc hasn't been through testing.

Kwpolska 2y ago
We ship a copy of bootstrap within our data files. They could just leave it as-is and have it working. Bootstrap is a CSS/JS library, there is no global /usr/lib to be concerned about.
- sangnoir 2y ago
  Most of HN who've been around know what Bootstrap is (rip, old Twitter). The same rules apply whether your package dependencies are .css, .js or .so
- cassianoleal 2y ago
  > because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package > there is no global /usr/lib to be concerned about Aside from possibly the path being different, which is of no concern, how can the 2 above sentences reconcile with each other?
  - Kwpolska 2y ago
    It is trivial to make the Bootstrap 3 global package install into a different folder than Bootstrap 2. It isn’t so trivial for shared libraries without different sonames, for example.