[Yum] YUM install [package.rpm] fails on Solaris, reports success

[Joshua Burns]

You do realize that you will be part of a very small number of
people deploying rpms on Solaris, yes? For instance if you try to
install "normal" packages, you'll have to somehow make rpm be happy
about the deps. provided by Solaris itself (libc, mv, rm, etc).
And, for instance, you are using the rpm package from RHEL-5 and a
yum+python that are significantly higher than those in RHEL-5 (and
python that is significantly lower than that in Fedora).

++++

Hi James, yes, we realize that RPM is not widely used on the Solaris platform, but the project goals include

1) a method of repository management, distribution and dependency management, and 
2) a single vector/tool/technology allowing a single set of packaging tools and a single repository across the enterprise

Apart from blowing big bucks on Tivoli/BladeLogic/etc., RPM/YUM seem like a fairly conspicuous choice. IBM has working RPM package[s] already for at least 1 or two releases of AIX, so that is 2 for 3. Although I haven't found YUM for AIX yet, it has been done: 

http://www.tekwire.net/joomla/building/rpm/rpm_AIX_5.2.htm

We already have "virtual" sysdeps and RPM packages that inform the database of the presence of shells, RPM itself, and the like, and these work fine. YUM, for example, a "normal" package, is itself installed via RPM on the Solaris host. 

++++++

I'm not saying it can't work, but I think to have a good chance of
success you'd want to have someone locally that has some understanding
of the internals of rpm+yum.

+++++++

Given that RPM seems to work fine, and YUM has compiled and most of its functionality also seems to work, it would seem we are at the 5-yard line. Granted, it is clear that we need to execute a thorough test plan before introduced into the wild, but do you consider the risk of failure really that significant? 

By "internals", do you mean depth of expertise of the API interface that may be involved in troubleshooting this particular issue? Everyone on the team has a lot of experience building packages and repositories (some for many years), and while it is not a trivial task over the long term, it is something that must be done to tame a very large environment. But no, we do not have an expert at that level at least in this particular vertical. Were I to suggest that it were necessary, we would probably have to scrap the plan as it is. I'm willing to do that, but I'd just as soon prove the capability of the open source tools if I have the opportunity. I have asserted that, once the tools are compiled and tested to be working (and we seem to be pretty close), the project risk will be greatly reduced. 

+++++++

It's not obvious why the scriplets success/failure would depend on
being run from the rpm/yum commands. Obviously they don't take exactly
the same code paths, but I'm still surprised.

++++++++

For what it's worth, I, too, was chagrined at having to report a surprise issue this late in the game. Having gotten this far, I had assumed that if RPM could install a given package, YUM would also succeed. 

Any help you are able to give would of course be greatly appreciated. This is a particularly key moment (a fork in the road, if you will) in the history of the company's infrastructure, and the successful use of this technology could have major impact on the adoption of open-source technology over open-wallet technology. 

++++++

Seth just meant that, from rpm's point of view, a package install has
still succeeded _if_ the %post has _failed_. Because for "normal"
packages that's the best thing to do.
Also even with a pure RHEL-5 set of machines, managing configuration
data with packages is problematic at best. There are configuration
management systems that are designed to do that kind of thing.

++++++

I understand. "Configuration" management is probably not the best term - the packages I referred to earlier are analogous to redhat-release. They [will, if the project is successful] be consulted by other packages to obtain information about their environment. 

++++++

-- 
James Antill -- james at and.org
_______________________________________________
Yum mailing list
Yum at lists.baseurl.org
http://lists.baseurl.org/mailman/listinfo/yum


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.baseurl.org/pipermail/yum/attachments/20091112/71310e5d/attachment.htm>