I really, really, really want feedback on this:
Over the past few months, I’ve really gotten into packaging on Fedora and Ubuntu. I’m not an expert, but I can genuinely say our packaging situation is crap. We are so close. And yet we ended up with two major implementations, that are almost the same. There is no significant difference between RPM and Dpgk.
So will Fedora abandon their 15,000 packages and choose Dpkg? Will Debian abandon their 35,000 packages and choose RPM? No. Neither will. There is no way for them to transition. And they will not give up their self branded solution. The only way forward is to make a new system, that is both better, and backwards compatible with RPM and Dpkg.
That is what I have been toying with for the past few months. It is called Packagetastic and It is a replacement for Dpkg and RPM, but still backwards compatible with them. Right now it is just a proof of concept, but can build many small packages on Ubuntu and Fedora.
I made a screencast to show how it works. This is just a simple, introduction. More example on how to use it will come soon. You can view the screencast below:
More information about the project can be found here: http://launchpad.net/packagetastic
Please provide your criticism and feedback at the mailing list, this blog post, or my identica page.
14 comments ↓
I think you’re underestimating the problems with packaging on Linux, actually.
First, there are a lot more than two packaging systems – RPM and DEB are the big ones, but there’s also autopackage, ROX 0install, whatever Arch uses, Gentoo’s ebuilds (which are a completely different beast), BSD-style ports (also completely different), Slackware tarballs, SLAX package images, etc, etc.
I haven’t looked at Packagetastic long enough to see how you’re handling dependencies, for instance, but mapping packages in one system to packages in another system isn’t trivial. Debian, for instance, splits a lot of packages into whatever and whatever-devel, so that regular users don’t get extra stuff they don’t need. Even if you did have a perfect mapping between RPM and DEB packages, the packages can also be compiled with different options, and a program that works with libfoo-1.0.rpm could easily break when you try to use it with libfoo-1.0.deb. RPM and DEB don’t provide enough dependency info to test for this; the only way to find out if it breaks is to try it out and wait for it to crash. It’ll usually work, but “usually” isn’t really good enough XD
If you’ve only looked at RPM and DEB so far, it’d be good to look at a few of the other packaging systems out there – there are a lot of good ideas floating around.
Hmm, looks like I might have misunderstood what you’re trying to do here. Based on the video, it looks like you’re creating a metadata file that can be used to generate either a DEB or RPM (or, hopefully, other stuff) – pretty cool!
As far as feedback goes, my earlier comment about package names still stands – you need some way to specify that a dependency has different names on different distros. It might be useful to have a way to depend on files being present on the system, as well, instead of just packages.
Actually, more generally: make sure that the file format allows enough flexibility with scripting (since it’s in python, shouldn’t be too hard) that you can handle whatever distro-specific weirdness you run into. Eventually, you’ll run into a situation that needs to be handled completely differently on different distros.
If you can make this easier to use than RPM spec files or whatever Debian uses, this will be a seriously interesting project
LSB says your distro is compatible with RPM.
The program that you describe already exist for a long time,
and its on repos of mayor distros, is named “SMART”,
it can handle DEB/RPM transparently.
@Ravi
Packagetastic is not designed to replace all packaging systems. Just the big ones that are similar to dpkg and rpm. It should coexist with Arch’s, ebuilds, and even others that want to stick with rpm and dpkg. It is more about making it easier for people that want to, to move forward. Later it should be able to build packes for other distros such as gentoo, slackware, arch, and foresight.
It is true that there may be issues with packages not mapping correctly between distros. It using a list to say what maps to each distro. Each distro has a standard way of setting their compiler options. In the case they do not match, we can rebuild that dependency. There may be cases where this does not work. We will have to find a way around.
I have looked at other packaging systems, including Conary, Gobo’s, Arch’s, Slackware’s, Gentoo’s, and all the application virtualization ones like autopackage and klik.
@Ravi
Hmm that misunderstanding is legitimate. It is a meta package that generates others in phase 1. Then phase 2 it can be a stand alone one.
@juancarlospaco
All Smart does is replace apt-get, yum and other tools that resolve the dependencies. So you can use it on both a rpm and dpkg distro. It does nothing to lessen the burden of having to create packages for each distro.
@juancarlospaco
I forgot the first part.
It is true that rpm is the approved lsb packaging format. But that means nothing to the debian maintainers with their 35,000 packages that have no way or desire to be converted. Many debian developers will tell you that lsb is crap.
matt: actually, you can convert debs to RPMs. There’s been a tool for this for years, it’s called alien. It even works, on fairly simple packages.
I’m with Ravi, though, in thinking you may be underestimating the problem. It’s not just about packaging formats. Have you ever tried using a Fedora package on SUSE, or Mandriva? Usually, it won’t work. Even if it works, you can’t take a Fedora spec file and use it to create a package that SUSE or Mandriva would consider valid for their repositories, unmodified. All distributions, even those which use the same package format, have different conventions in terms of libification, package naming, macro use and various other points.
Having said that, anything which helps bring projects closer together is to be welcomed, so don’t give up
just be aware it may be a long trek…
@Adam Williamson
I spent some time playing with the Alien source code, when I was doing research for this project. It is surprising small, for what it does. The problem with Alien, is that it is dealing with the finished binary packages or source packages. If you take them apart and look at them, there is critical data missing, and much of it is dealing with something distro specific. So there is not much it can do to convert everything from dpkg to rpm. That is why it fails with moderately complex packages, or is unreliable.
You have the same kinds of problems if you try to automate converting rpm spec files to debian control and rules files. The information is just not all there, and not all doing the same kinds things. So with packagetastic, I am trying to make a kind of rpm spec/debian control/rules meta file, that has all the data needed to generate the source packages for rpm and dpkg.
Right now I am kind of redefining what the project is trying to achieve, based on feedback. You can see more at the temp home page: http://workhorsy.org/packagetastic/. I will make a better blog post on that in a few days.
And about the differences between rpm distros. I’ve briefly looked at how mandriva, open suse, and others are different from fedora. I’m not sure of all the details, but it should be just a matter of changing a few details from how me generate the fedora rpms.
Thanks for your feedback. It is definitely helping to mold the project.
testing 2.9 upgrade
Did you try the openSUSE build service ?
https://build.opensuse.org/
It can automatically create packages (and solve build-time dependencies) for distros like openSUSE, SLED, Fedora, Ubuntu, as long as you provide the spec file.
I could see a good use for Packagetastic there.
@Vincent Petry
They must have updated it, since the last time I played with it. Do you have a link that shows more info on how they build debian packages from rpm spec files? I don’t see anything like that listed on their site.
Actually, you can’t. You have to create specification files for the Debian packages to do that. I didn’t try it myself. There are some instructions here: http://en.opensuse.org/Build_Service/Deb_builds
It means that when you create cross-distribution packages you have to provide the specs for all the package types. See http://en.opensuse.org/Build_Service/cross_distribution_package_how_to
What would be interesting is to have packagetastic run before the real build starts. It would generate the spec files for the target distro.
@Vincent Petry
Okay. I was beginning to think that is what you meant. I just misunderstood what was written. That is a good idea. I will have see if I can use their build service to do the actual building.
Leave a Comment