Comments on: I want an ‘rpm2all’ tool http://iquaid.org/2009/06/18/i-want-an-rpm2all-tool/ ... the four laws of humanity ... Tue, 15 May 2012 07:18:22 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: greg http://iquaid.org/2009/06/18/i-want-an-rpm2all-tool/comment-page-1/#comment-3130 greg Tue, 23 Jun 2009 22:48:49 +0000 http://iquaid.org/?p=660#comment-3130 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. 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.

]]> By: quaid http://iquaid.org/2009/06/18/i-want-an-rpm2all-tool/comment-page-1/#comment-3119 quaid Thu, 18 Jun 2009 21:54:22 +0000 http://iquaid.org/?p=660#comment-3119 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. 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.

]]> By: Andrew Overholt http://iquaid.org/2009/06/18/i-want-an-rpm2all-tool/comment-page-1/#comment-3117 Andrew Overholt Thu, 18 Jun 2009 19:49:37 +0000 http://iquaid.org/?p=660#comment-3117 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. 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.

]]> By: Jef Spaleta http://iquaid.org/2009/06/18/i-want-an-rpm2all-tool/comment-page-1/#comment-3116 Jef Spaleta Thu, 18 Jun 2009 19:36:33 +0000 http://iquaid.org/?p=660#comment-3116 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 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

]]>