Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No I don't. I use Debian derivatives because I can apt get all my stuff without thinking hard, because those package maintainers have done the hard work.


Well, clearly not, since you can't install Hadoop. Before you blame that on Hadoop, remember that it only requires some really quite basic things from its package manager, which apt is nevertheless completely unable to do: use libraries in the normal recommended way, play nice with Java, work cross-platform.


Whatever. (Great practices those, being stuck in a decade old JVM and requiring root to build! But well, whatever.)

If I can not install on Debian in a clean way, I will just try to avoid using the software (and everything that comes on the ecosystem). It may be unavoidable, but if there is an alternative, it will be preferred. If one alternative appears after I am dealing with it for some time, it is still preferred (because the work with out of distro software never ends).


> Well, clearly not, since you can't install Hadoop.

You are complaining that you can't automatically install broken packages out of the box through the official repo.

And packaging an application is the responsibility of the people working on that application, not the OS.

What's your point?


An OS is a tool for running applications, not vice versa. Packaging an application should indeed be the responsibility of people working on that application, which is why language package managers like maven are successful. Debian explicitly rejected this philosophy in favour of one where OS maintainers are responsible for packaging all applications (thus the OS-specific packaging format and closed-world assumption of their package manager).


> Debian explicitly rejected this philosophy in favour of one where OS maintainers are responsible for packaging all applications

That assertion is quite wrong. Just because the OS has its official package repository, and just because OS maintainers volunteer their time to package some software projects, obviously that does not mean that maintainers are responsible for anything. You are confusing offering a convenience service with being responsible for packaging each and every software under the sun.

In fact, your baseless assertion ignores two basic facts: packages are proposed and adopted by volunteers, thus what you've described as "OS maintainers" is pretty much any random person who simply wants a software to be available for download in the distro's official repositories, and packaging systems such as Debian's apt supports private package repositories, where anyone can make available their packages to the world.

Another fact that you missed is that build systems such as Maven or msbuild or cmake or Gradle or whatever do support download packages only for a reason: convenience. It has absolutely nothing to do with where lies the responsibility of providing packages. It's convenient that a build fulfills all build dependencies. However, the responsibility of packaging and distributing packages of a software product lies exactly where it always was: those working on the software product.


> packages are proposed and adopted by volunteers, thus what you've described as "OS maintainers" is pretty much any random person who simply wants a software to be available for download in the distro's official repositories

The entirety of the Debian project are volunteers, random people who simply wanted xyz. And Debian's raison d'etre is as a "distribution" of existing software.

More to the point, Debian packagers explicitly overrule "upstream" application developers; see the history of cdrecord or the ssh key generation bug for particularly spectacular examples. How can you say it's the responsibility of those working on the software project when they don't get to make the final decisions?

> packaging systems such as Debian's apt supports private package repositories, where anyone can make available their packages to the world.

Not really, because apt's approach to dependencies requires a central naming authority. In practice any private repository is necessarily a dead end: you can package additional software that depends on software from the central system, but not vice versa.


For Linux distros, the primary responsibility for packaging is actually with the distro maintainers, since packaging is distro-specific.

That said, a well-written app should not present any difficulty for the package maintainer.


> For Linux distros, the primary responsibility for packaging is actually with the distro maintainers, since packaging is distro-specific.

No it is not. Although distros might pick and adopt some packages and include them in their official repository, it's obvious to anyone that as a distro maintainer you are not responsible for packaging each and every software package under the sun.

Moreso, linux distros such as Debian rely on volunteers to propose and adopt packages, which obviously also includes people affiliated with each software project.

Additionally, it's patently obvious that the responsibility of packaging and making a software available to the public lies on the people involved in developing the software project.

> That said, a well-written app should not present any difficulty for the package maintainer.

That is true, particularly as the primary package maintainers are in fact those actually developing the software project.


How many packages in the Debian repos are packaged by their authors, rather than maintainers that are affiliated with the Debian project?

(I'm including volunteer maintainers in the latter category, unless they submit the package to the original author rather than directly to Debian.)


I don't need Hadoop because I have find, xargs, GNU parallel, Slurm etc etc




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: