The open source software companies (ISVs) that I’ve been talking with about Fedora have a common problem. Ironically they, as usual, are resolving this problem individually. Making an RPM that relies upon system packages is not seen as desirable, as it reduces their portability and focuses (in their minds) on one delivery platform — RPM-based Linux, specifically Fedora and Red Hat Enterprise Linux (RHEL). They see that as artificially limiting the pool of customers.
What if we had a tool that could take a proper Fedora RPM and build other targets such as ZIP files? In the process, it would download and bundle the dependencies instead of relying upon system packages.
Why would we care? Honestly, the only platform I care gets good packages is Fedora and friends. If one of these ISVs customers is running Fedora, RHEL, or a RHEL clone such as CentOS, I want those customers to have a better RPM-based experience. If those customers are running another OS, there is little I can do to help their experience, and we don’t have time to care.
But if I can make the ISVs lives easier, or at least no harder than before, that is a way we can help make Fedora-based distributions better.
Our argument that there it is a strategic investment to build good packages is falling on deaf ears. The common viewpoint sounds like this: “Our customers are not demanding RPM packages, they don’t want to feel we are pushing a Linux-based solution of any kind, after all we’re Java and run anywhere, and have you looked at how hard it is to package Java apps for Fedora?”
From a business viewpoint, I understand. Being able to convince them to re-engineer in the middle of the race is going to take a lot more understanding than I can give them in five minutes here and there. So I got to thinking … if they ran Fedora or RHEL as a development, build, QA, and release engineering environment, but they could get an installer out the other side for any OS (ZIP, EXE, BIN, DEB, OpenSUSE RPM, Mandriva RPM) using some kind of magic ‘rpm2all’ tool, would that be compelling?
I know there is a lot more to it than I’ve described. I bet the MinGW cross-compiler has something to do with it. They might still need to specify mapping details for the conversion or plug in a proprietary installer builder.
But just as an idea … what do you think?
Sounds like a a mash up of alien, checkinstall and autopackage.
All of which have their own particular weaknesses dealing with differences in packaging semantics across the distribution build policy boundary.
I don’t think you are going to find a workable,reliable solution here.
But you may want to take a look at packagekit’s Service Pack concept work as a starting point for a new effort in this area.
http://www.packagekit.org/pk-faq.html#service-pack
-jef
It’s not hard to package java stuff for Fedora. People just have a real mind block against it. That, and they’re not used to building from source and not re-shipping their dependencies.
Yeah, Andrew, I keep hearing, “That will take us two or three weeks.” Um, I think, and is that a long time? Sounds like a short amount of trouble for a long term result. But I’m known to be stupid, of course.
One part of my job is packaging closed source software so that we can distribute it across our customer base via a Red Hat Satellite Server. Its never a fun thing, but having had to spend my time doing this and being very upset at all of these vendors for not distributing RPMS* I can tell you the one thing that makes life bearable is silent installers. At least if they “think” their GUI installer is the better experience, with a silent installer the sysadmin can take the horribly ugly (not looks) installer that few of us want anyways and wrap it with something useful to us, be that RPM or deb or any of the other numerous options.
One thing I would like to see is a hosting spot for SPEC files, control files, etc. Effectively someone like me who has to package one of these could make one as standard based as possible, and post it without the Vendor’s installer. Versioning could be managed, a bug tracker implemented, and hopefully some kind of “check here to show VendorX you want this packaged properly from them”. It would take a while to gain popularity, as most people aren’t big fans of packaging on their own, but it could be made usable. I’ve implemented Makefile scripts in my build directories so that I just checkout the repository, add the Vendor’s installer, type make, and voila 🙂 Its hardly any different from a regular packaging process.
For a quick rant:
The ones that are really bad are the ones that install rpms as part of their installer, but do so much inside the wrapper script or the pre/post scripts that half the RPM benefits are immediately lost!
* I don’t understand whats wrong with providing an RPM when you say you only support RedHat and SuSE 🙂 I get that just installing to any linux unofficially supports more customers, but you shouldnt get your cake and eat it too. You support all or just Red Hat/SuSE! Its such a lame stance to take.