[I am not on [EMAIL PROTECTED] --- This post may
bounce there]
On Sun, 18 Jun 2000, Stefan van der Eijk wrote:
> ;-) Well, I'd just like to look at it from a general rpm
> point of view. When you do this while recompiling redhat's
> rawhide (or any rpm-based distro that changeds alot) on a
> regular basis you'll probably get these problems.
hmmm ... I run from CRON shell scripts which attempt to 'rpm
-ba' recompile _ALL_ Redhat, Kirk Bauer, Owl River, and
selected other SRPMS automatically, repeatedly, on i386,
Alpha, Sparc, and Mips-el, from RH ver. 5.0 on, daily, on an
automatic and unattended basis, seeking to automatically
back-version port, and cross-platform port. There are 30-40
packages with either circular dependencies, or later library
features which simply will not back- or cross-port.
> * One more word on package building. When working on a distro
> it's tough keeping everything consitant. What I'm actually
> looking for is a utility that does the following:
>
> - Detects if a new src.rpm is found
A simple shell script, using the slocate database, running
after the nightly updateddb is our approach.
> - Removes the installed rpm of this src.rpm and all the packages
> that depend on it.
... Ummm ... you don't want to do this -- instead, first
attempt to rebuild the new SRPM locally. If the 'rpm -ba'
succeedsm it will leave a -new- SPRM in the build tree
hierarchy (/usr/src/redhat/x in RH; Mandrake uses
/usr/src/???/x -- I forget, but it is obvious with a machine
at hand.
> - Builds each of these packages in the order of dependancy and
> installs them when they're built.
Well ... in like fashion, it will leave behind ./RPMS/i386,
./RPMS/noarch, etc. installable packages --- We haven't added
automatically installation here, because of a concern about
maintaining a known build environment, but there is no reason
that this could not be done.
I think I would probably instead mirror the end product to an
Anon. FTP site, and set AUTORPM to use that site as its
'pool'. This will then use the later version determination
logic in autorpm to attempt what you wish to do.
> I beleive somthing like this is the only way to combat dependancy
> issues when building... Redhat & Mandrake & SuSE probably have
> something like this already...
... Last month, JBJ at RH mentioned that there were perhaps a
dozen packages which cannot resolve this way. One of the
reasons that a RH Upgrade requires a boot is that the upgrade
process they use solves the dependency issues outside of the
RPM mechanism, and it may safely do a --nodeps, --force
install, because, assuming it successfully completes, it will
later have satisfied the Dependencies.
We at Owl River have made some attempts at automatic
Dependency detection and satisfaction, with some scripts, but
are unhappy at their efficiency, and need for manual 'hints'.
(See our presentation notes a couple of months ago at the
Central OH Linux User Group Presentations site:
http://stones.wcbe.org/~COLUG/ )
I presume you are aware of the --querytags available, and
carefully parsing output from that, against a pool of
available packages, permits the dependency reesolution you
seek.
--
end
==================================
.-- -... ---.. ... -.- -.--
Copyright (C) 2000 R P Herrold
[EMAIL PROTECTED] NIC: RPH5 (US)
My words are not deathless prose,
but they are mine.
Owl River Company 614 - 221 - 0695
"The World is Open to Linux (tm)"
... Open Source LINUX solutions ...
[EMAIL PROTECTED]
Columbus, OH
