From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dmitry V. Levin" To: devel@linux.iplabs.ru Message-ID: <20001112154908.A20920@LDV.fandra.org> Mail-Followup-To: devel@linux.iplabs.ru Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline Subject: [devel] [jbj@redhat.com] Sender: devel-admin@linux.iplabs.ru Errors-To: devel-admin@linux.iplabs.ru X-BeenThere: devel@linux.iplabs.ru X-Mailman-Version: 2.0beta6 Precedence: bulk Reply-To: devel@linux.iplabs.ru List-Help: List-Post: List-Subscribe: , List-Id: IPLabs Linux Team Developers mailing list List-Unsubscribe: , List-Archive: http://www.logic.ru/pipermail/devel/ X-Original-Date: Sun, 12 Nov 2000 15:49:08 +0300 Date: Sun, 12 Nov 2000 15:49:08 +0300 Archived-At: List-Archive: List-Post: --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings! =E4=CF=D7=CF=CC=D8=CE=CF =CC=C0=C2=CF=D0=D9=D4=CE=D9=C5 =D2=C1=D3=D3=D5=D6= =C4=C5=CE=C9=D1: ----- Forwarded message from Jeff Johnson ----- Date: Sun, 12 Nov 2000 04:58:30 -0500 From: Jeff Johnson All -- > The package ordering algorithm in rpm is gonna change. >=20 > Here's a simple test to illustrate the need for the change (from > bugzilla #12327): >=20 > Assume the minimal 7.0 package manifest in /tmp/list > /mnt/redhat/comps/dist/7.0/sparc/bash-2.04-11.sparc.rpm > /mnt/redhat/comps/dist/7.0.2/sparc/glibc-2.1.94-1.sparc.rpm > /mnt/redhat/comps/dist/7.0/sparc/mktemp-1.5-5.sparc.rpm > /mnt/redhat/comps/dist/7.0/noarch/basesystem-7.0-2.noarch.rpm > /mnt/redhat/comps/dist/7.0/noarch/setup-2.3.4-1.noarch.rpm > /mnt/redhat/comps/dist/7.0/noarch/filesystem-2.0.7-1.noarch.rpm > /mnt/redhat/comps/dist/7.0/sparc/libtermcap-2.0.8-25.sparc.rpm > /mnt/redhat/comps/dist/7.0/noarch/termcap-11.0.1-3.noarch.rpm >=20 > with database initialization as > mkdir -p /tmp/ROOT/var/lib/rpm > rpm --initdb /tmp/ROOT/var/lib/rpm >=20 > This command "works" > rpm -Uvh -r /tmp/ROOT `cat /tmp/list` > while this command > rpm -Uvh -r /tmp/ROOT `tac /tmp/list` > fails with=20 > loop in prerequisite chain: libtermcap bash libtermcap >=20 > The problem is that the current ordering algorithm, basically a very clev= er > implementation of tsort, is sensitive to initial conditions, and the first > command "happens" to snip a loop, while the second does not. >=20 > I've reimplemented a notso-clever tsort from Knuth V1, but there's one fu= rther > twist. Since the only way out of a dependency loop is to snip the loop > somewhere, rpm needs a hint about where to make the cut. The short term h= ack > will be to cut dependency loops by removing all PreReq:'s in the loop. >=20 > If that seems counter-intuitive, you might consider the loop above: > bash has > Requires: libtermcap.so.2 > libtermcap has > PreReq: /bin/sh > Cutting on the PreReq: potentially breaks one package, libtermcap, while > cutting on the Requires: may break an entire install (i.e. no /bin/sh). Above is my original message. OK, snipping on PreReq:'s was a counter-intuitive hack, now repaired in rpm-4.0.1-0.7. What is implemented now is that there is syntax to explicitly specify the source of a Requires: dependency. If, for example, you use grep in %pos= t, then you as a packager would normally add PreReq: grep in order to insure that grep was installed before attempted use by %postou Now the same dependency can be expressed more precisely as Requires(post): grep For completeness, here's the complete set of tokens that may be added to Requires: as in the example above: "interp", RPMSENSE_INTERP "prereq", RPMSENSE_PREREQ "preun", RPMSENSE_SCRIPT_PREUN "pre", RPMSENSE_SCRIPT_PRE "postun", RPMSENSE_SCRIPT_POSTUN "post", RPMSENSE_SCRIPT_POST "rpmlib", RPMSENSE_RPMLIB "verify", RPMSENSE_SCRIPT_VERIFY Ditto BuildRequires: "prep", RPMSENSE_SCRIPT_PREP "build", RPMSENSE_SCRIPT_BUILD "install", RPMSENSE_SCRIPT_INSTALL "clean", RPMSENSE_SCRIPT_CLEAN but let's not go there (yet). For giggles, you can also do stuff like Requires(pre,post): /bin/sh By marking dependencies more precisely, rpm can distinguish between an upgrade context (like the use of grep in %post above) and an installed context (like the autogenerated Requires: in a package that includes a script with #!/bin/sh), and that permits rpm to differentiate pre-requisites from co-requisites while doing package ordering. Here's what cures the libtermcap <-> bash loop: Requires(postun): /bin/sh which, since the dependency is clearly not useful or necessary in determini= ng install ordering, is safely ignored. In order to start flushing PreReq's everywhere, I've looked at all of 7.0/6.2/6.1/6.0/5.2 "everything install" ordering, and am able to order packages successfully when given an alphabetically sorted list of packages both forwards and backwards. That should catch most all the loops, maybe not, we'll see. At the moment, I've hacked dependency "white out" directly into rpmlib to eliminate the following (new) package loops: This needs That (i.e. is eliminated or there's a loop) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D libtermcap bash modutils vixie-cron ypbind yp-tools ghostscript-fonts ghostscript /* 7.0 only */ pango-gtkbeta-devel pango-gtkbeta XFree86 Mesa compat-glibc db2 compat-glibc db1 pam initscripts kernel initscripts initscripts sysklogd /* 6.2 */ egcs-c++ libstdc++ /* 6.1 */ pilot-link-devel pilot-link /* 5.2 */ pam pamconfig Why are there new loops? Because my tsort is trying to use all of the dependency info for ordering, while ewt's tsort ignored all Requires: from added packages. Except for the well known libtermcap <-> bash loop (which is just wrong), all of the other dependencies are simply not needed in an upgrade context to perform package ordering. Please note that the dependencies are not removed, only ignored for the purposes of determining package ordering during install, hence "white out". While applying "white out" in rpmlib is a very, very, dirty hack, I believe that the hack is expedient, as it's really gonna take a while to rebuild all of the above packages, get the errata out, inform support, etc, and I really, really, really don't want to be explaining pre-requisites and co-requisites again, and again, and ... Yes, the "white out" hack will be removed as soon as possible. So what does this all mean? Basically not much, as it's gonna take at least a year to flush PreReq's from legacy packaging. And, before you start adding new-fangled syntax to packages, please remember that rpm will be auto-gener= ating fine-grained dependencies for %post et al scriptlets using the bash hack to identify tokens used in an exec context within a shell script long before the year is up. FWIW, what still needs doing is adding support for Requires: PATH(foo) with semantics, essentially, of dependency is satisfied if foo exists in $PATH, as scriptlets can and do use relative paths. Off to figger how rpm-4.0.1 polluted the SBE compose (I believe that's what happened) and what's going on with signing ... Cheers 73 de Jeff ----- End forwarded message ----- Regards, Dmitry +-------------------------------------------------------------------------+ Dmitry V. Levin mailto://ldv@fandra.org Software Engineer PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html IPLabs Linux Team http://linux.iplabs.ru Fandra Project http://www.fandra.org +-------------------------------------------------------------------------+ UNIX is user friendly. It's just very selective about who it's friends are. --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6DpHDZqIoNiVITrsRAq3MAKC+pBpVKDICHLeS3vWvrgu+wPVn3wCgu0K6 Sr/j9e47SOs3efMToP/j6co= =hTj9 -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- _______________________________________________ Devel mailing list Devel@linux.iplabs.ru http://www.logic.ru/mailman/listinfo/devel