There is alien[1], but I'm not sure if it is flawless, because of slightly different ways of doing things across distros like /etc/default vs /etc/sysconfig for example.

Depending on how good is the source, its usefulness and dependencies, packaging it to Debian is pretty straight forward. The dh_* helpers[2] does the job automatically most of the time. There is also tools for helping with specific languages, like dh-make-golang, dh-python, etc...

[1] https://packages.debian.org/buster/alien

[2] https://manpages.debian.org/testing/debhelper/debhelper.7.en...

From the looks of it, alien is just a tool to convert between different package formats and is not a replacement for proper packaging work. Very much like how you can’t take a deb package from different releases of the same distro and expect things to work properly, you can’t just take RPMs from CentOS to a whole different distro and expect things to work.

It’s not only the differences in the packaging format that you have to take care of. There’s also version differences, path differences, dependency handling, and many other stuff to take care of. These are the kind of tasks which can’t be automated away and require non-trivial amount of work.

For organizations that maintain tens, hundreds, or thousands of CentOS packages that spans multiple teams, moving to other distros would be time-consuming and costly. It would certainly pay off if it was driven by technical reasons, but for organizations that are forced to switch by this announcement, this is just pure overhead.

>Java , postgres and tomcat

That's his stack...

>So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro,

It's not magic, just alien.

> >Java , postgres and tomcat

> That's his stack...

What’s your point and when did I ever mention Java?

> It's not magic, just alien.

Dumping the contents of an RPM archive on random distros is never going to work except for the most simple of cases.

>Dumping the contents of an RPM archive on random distros is never going to work except for the most simple of cases.

That says allot about you packing hygiene, and you don't dump it..that you can do with tar alone. You convert it to a deb.

That says a lot about your packaging hygine. With alien, you're essentially dumping the contents of an RPM on hosts it wasn't meant for. It doen't matter that you converted it to deb format along the way, it's the same if you actually install it.

MyMy, you have no clue how packages and a package-manager works right?

Did you ever read a single line of alien source code? It extracts the metadata and files from a package, and re-archives it. That’s about it. It doesn’t handle package version differences, path differences, distro-specific rules, nothing. If your package has dependencies, forget about it because alien won’t retain dependency information it all. In other words, it only “works” for the most simple of cases.

I suggest you read the source code too, because otherwise you can cause real damage if you use it without understanding how it works.

https://sources.debian.org/src/alien/8.95/alien.pl/

Took me a minute to figure out where that came from, it was in the GGP comment.

But surely if you depend on those packages, you can maybe track (or just collect) their versions, then get the same versions in another package manager (possibly via pinning).

Though my experience with package manager is that dependency management is hell (rife with potential conflicts), so I do see the problem a bit better.

Still, it shouldn't take that long to fix? Like a few days of sprint to setup Nix or something like that?

I think it depends on the number of packages that you maintain. If it’s only a handful of packages, the entire process of repackaging, testing, and deployment might be doable in a matter of days. If it’s tens or hundreds of packages that depend on each other, I think that’s a whole different story. If those packages are maintained by different teams, it could take more than an year to complete the transition.

As for pinning packages, that’s only practical if you’re using Nix. As much as I prefer Nix over RPMs, not all of us have the pleasure of using Nix at work. It’s kind of a bummer because Nix packages are so much easier to work with and maintain compared to the competition.