Hacker News Reader

Comment by codavid | Hacker News Reader

The .rpm vs .deb debate is a fallacy. The real issue is that when packaging for say debian and RHEL you have to care about different glibc, different compiler versions with potentially different ABI, different filesystem conventions, different scripts for post install, etc... The format in which the files are packaged is the least of the issues compared to that. For example, packaging for opensuse once you have a package for RHEL is as much of a PITA than packaging for debian, really.

Once you standardize on what makes packaging difficult across distro, you basically end up with the same system. I think systems like the build service from Suse, etc... are much more useful than wishful thinking on packaging format.

View on HN

Yes, suse build service is a very nice tool and much more interesting than a single package format, which wouldn't help much. And if the dream is to provide just a single binary package for any distro in the world, it won't work anyway. Well, maybe in theory, but if you mean it seriously, you need to compile and link against exactly the same binaries that the target system use. (Or static linking. Or just believe it will work. But serious commercial vendor who wants to provide a real user support cannot.) Which would mean that every Linux system would have to use the same binaries, which is, hm, nonsense.

Meh, from a source point of view, once I have a debian/ directory, with a properly set up rules file, building becomes trivial. Then it is matter of generating a package per-distro/version with the right environment. This could be very well done in an automated manner and a few vms.

Which is exactly what the build service gives you...

My bad, I was under the impression that it was an RPM only thing.

I hear what you are saying, but we can reduce the differences between build systems while still using different targets.

I do a lot of work with OpenEmbedded, every distro image you create is for a different hardware platform, using different libraries, different tools, etc. But it is a unified build system. So I can say use this version of glibc and spit out the files in that folder, and with very minor tweaks I can use a completely different version of glibc and a different file structure for another image. If we had a unified dependency/build system across distros, we could have completely different contents while having relatively straightforward customization because if you knew one system, you'd know them all.

Reply on news.ycombinator.com