On Jul 23, 2010, at 3:12 PM, Tim Mooney wrote:
> In regard to: Issues with rpm-5.0.3 - overwrites other RPM's, Robert Cohen...:
>> We've built, and had been using for years, our own instance of rpm 4.0.3, and it worked a treat. Our platform was Solaris 8/9/10, on sparc.
> I did the same with rpm 2.5.6 and then 4.4..
;-) Now there's a whole lotta history in that transition ;-)
>> Recently, we started using solaris10 on x86, and figured it was a good time to upgrade our rpm environment.
> I do a lot of building on x86_64-pc-solaris2.10. I upgraded to rpm 5.1.9
> about 4 months ago. Joshua Burns' post from December 4th, 2009 had some
> useful tips on build issues with 5.x, so I as prepared for most of what
> I ran into.
Yes. I'd forgotten that post about RPM + Solaris.
My own most recent experience with Solaris was back in March,
when I tried to do "make check" in a Solaris VM.
The paucity of OSS tools to set up a build environment was
a bit depressing. But I still have the VM (and Nexenta seems
like a reasonable alternative approach) both lurk on my todo
list somewhere because of
1) ZFS snapshotting as a form of --rollback
2) SEEK_HOLE/SEEK_DATA used to install files sparsely
I can revisit RPM -> Solaris anytime there is interest.
>> I got 5.2.1 built, but something weird is happening. When we install rpm's that we produce within the rpm environment, the rpm installation silently overwrites files belonging to other rpms rather than detecting
>> conflicts. rpm seems to pay attention to prerequisites, and conflicts
>> specified in the SPEC, but rpm --install/--upgrades will
>> delete/overwrite files that were installed via rpm.
> Hmmm, I've not seen that with 5.1.9. With one very minor exception, 5.1.9
> built pretty easily and the upgrade process from 4.4.9 to 5.1.9 worked
> without a hitch, which I wasn't really expecting.
Most of that portability from 4.4.9 -> 5.1.9 came from OpenPKG methodology
and Ralf Eneglschall's attention to details.
Note that the transition for rpm-5.1.9 -> 5.2.1 is pretty easy, but
that is very much not true moving to "RPM ACID" as in rpm-5.3.x,
where no "compatibility" is promised, and the conversion issues
aren't yet sufficiently well defined to attemp a shrink wrapped
But rpm-5.3.2 with a clean install is fine, its only the schema changes,
and the transition that is rugged. The performance is considerably
better, an Berkeley DB ACID eliminates most side-effects from interrupted
installs, etc, etc.
> I had issues with the dependency generator not finding ELF library
> provides correctly after the update, but discovered that was because
> 5.1.9 doesn't build with libelf support by default (you have to request
> it). Once I did that and then hacked out tools/debugedit so that wasn't
> built, everything worked very well.
SIs you use the Sun ELF or something else? It likely would not be
hard to add a test for Sun ELF implementation to rpm's AutoFu if useful.
>> Even the build process for rpm5 seemed dodgy, as I had to do things like copy in find-provides, find-requires, and configure them into the macros file by hand.
> I don't remember having to do any of that. I certainly customized a macro
> or two, but nothing major.
>> The build of 5.0.3/5.2.1 was against gcc 3.4.3, using GNU make, and involved the installlation of beecrypt, zlib, and popt from 3rd party sources, into /usr/local/rpm, before attempting to build rpm as I have been unable to get the copies distributed with RPM to build.
> I built my own copies of stuff beforehand in many cases. I'm using
> the Sun Workshop 12u1 compilers, so if anything your builds should have
> been easier. I probably had the most trouble getting rpm to use my
> copy of neon, but that's because neon builds static libraries only by
> default and there's no good way for RPM's configure to discover that neon
> depends on things like libssl and libkrb5.
For reference: What version of neon?
Also for reference: If you send along the configure options you used
(like in config.log) then I'll add to devtool.conf as a "reference"
Solaris configure options.
I'm still not happy with the myriad configure options needed
to build RPM these days, but devtool (also from Ralf Engelschall)
does make the complexity almost painless. Its the iteration
deciding what to turn on and what not that is hardest when
building RPM from scratch. With >30 configure options that
is a rugged decision path.
Glad to here you're still using RPM ;-)
73 de Jeff
Received on Fri Jul 23 22:16:02 2010