> Sure, I'm comparing with the JVM per the article. Fair enough, though I still use RPM's to deploy Java (Spring Boot even!) applications. > Indeed, but 10 mi

> Sure, I'm comparing with the JVM per the article. Fair enough, though I still use RPM's to deploy Java (Spring Boot even!) applications. > Indeed, but 10 minutes here, 10 minutes there, it all adds up. In the grand scheme of software development updating the .spec file or debian control file is peanuts. > No, I mean some native libraries not installed. Does your package declare what packages it depends on? How do you handle different distributions using different package names for the same libraries. In the case of RPM based distributions, some conditional macro's in the .spec file that swap out Requires/BuildRequires statements based on the distribution the package is being built for. I never bother with SUSE personally, but there are differences between EL7 and Fedora that I have to keep track of. > But if there's no clear standard everyone ends up doing it slightly differently, and then every project you pick up you have to understand how they've set things up. .spec files are more standard than most build tooling. The only thing that complicates them is projects without an adequate build system in the first place, everything else is minor style differences based on who wrote the spec. Everything has been done before, unless you are using some extremely new or extremely niche language or build tool chances are your spec file will be easy to figure out, since any and all complexity is explicitly linked to how easy it is to build and install your software in the first place.