Re: [gentoo-user] Re: libtool problem
On Wednesday 04 February 2009 22:40:26 Dirk Heinrichs wrote: > Am Mittwoch, 4. Februar 2009 21:21:38 schrieb Alan McKinnon: > > On Wednesday 04 February 2009 20:17:33 Dirk Heinrichs wrote: > > > Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD: > > > > The reason there wasn't a bump (IIRC) was that the ebuild never > > > > changed - only the eclass did. If you emerged any version of GCC > > > > during the window where the eclass was broken, that version of GCC > > > > would have been broken. > > > > > > That also means that portage is broken. Whenever something changes > > > where other things depend on, those other things should be rebuilt. > > > This doesn't happen here. > > > > I disagree, that would cause many more spurious rebuilds than is needed > > if it were automated. > > Why spurious? The package manager should be smart enough to tell the user: > "Rebuild because of eclass change". Nothing spurious. Portage only knows that the eclass changed. It does not know what the result of that change will be. Therefore it is not in a position to mandate that a rebuild of other apps is *required* in order to function correctly. Which leaves us with two options: Tell the user to look and decide for themselves, or Rebuild everything using the eclass anyway The latter option will always fix problems but at a huge cost of most often rebuilding something that looks like it needs rebuilding but actually doesn't. Therefore spurious. > > Portage cannot tell how important or how deep a change > > is, that requires a human to look and see. So what is needed is a flag > > that portage recognizes as an instruction to do a revdep-rebuild-style > > search and find everything using a specific changed file, and rebuild > > those. The flag is set under dev control. > > Not dev, user. Something equivalent to --newuse. I was thinking more along the lines of what @preserved-rebuild does. Some mechanism in the ebuild that includes a package in a list of stuff to be rebuilt. Obviously this is something new and a fairly deep change to portage so I can't think of a decent parallel or analogy. > > Blindly doing what you suggest leads to this: > > > > appA depends on libB. > > No. Sorry if this was misleading. I was only referring to dependencies > between ebuilds and eclasses. OK > Library interdependencies are handled just fine by portage/revdep-rebuild. > > > Therefore, a simple elog entry is a valid handling and fully compliant > > with the principle of The Simplest Thing That Could Possibly Work. > > Elog entries are overlooked too often. True, but do we have anything better? As in a proven mechanism successfully used elsewhere to deal with comparable situations? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: libtool problem
Am Mittwoch, 4. Februar 2009 21:21:38 schrieb Alan McKinnon: > On Wednesday 04 February 2009 20:17:33 Dirk Heinrichs wrote: > > Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD: > > > The reason there wasn't a bump (IIRC) was that the ebuild never changed > > > - only the eclass did. If you emerged any version of GCC during the > > > window where the eclass was broken, that version of GCC would have been > > > broken. > > > > That also means that portage is broken. Whenever something changes where > > other things depend on, those other things should be rebuilt. This > > doesn't happen here. > > I disagree, that would cause many more spurious rebuilds than is needed if > it were automated. Why spurious? The package manager should be smart enough to tell the user: "Rebuild because of eclass change". Nothing spurious. > Portage cannot tell how important or how deep a change > is, that requires a human to look and see. So what is needed is a flag that > portage recognizes as an instruction to do a revdep-rebuild-style search > and find everything using a specific changed file, and rebuild those. The > flag is set under dev control. Not dev, user. Something equivalent to --newuse. > Blindly doing what you suggest leads to this: > > appA depends on libB. No. Sorry if this was misleading. I was only referring to dependencies between ebuilds and eclasses. Library interdependencies are handled just fine by portage/revdep-rebuild. > Therefore, a simple elog entry is a valid handling and fully compliant with > the principle of The Simplest Thing That Could Possibly Work. Elog entries are overlooked too often. Bye... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: libtool problem
On Wednesday 04 February 2009 20:17:33 Dirk Heinrichs wrote: > Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD: > > The reason there wasn't a bump (IIRC) was that the ebuild never changed > > - only the eclass did. If you emerged any version of GCC during the > > window where the eclass was broken, that version of GCC would have been > > broken. > > That also means that portage is broken. Whenever something changes where > other things depend on, those other things should be rebuilt. This doesn't > happen here. I disagree, that would cause many more spurious rebuilds than is needed if it were automated. Portage cannot tell how important or how deep a change is, that requires a human to look and see. So what is needed is a flag that portage recognizes as an instruction to do a revdep-rebuild-style search and find everything using a specific changed file, and rebuild those. The flag is set under dev control. Blindly doing what you suggest leads to this: appA depends on libB. libB has a bug which is fixed but no changes to the API or ABI occur, so appA does not need to be rebuilt, it simply uses the new compiled lib when run. This circumstance will likely happen many many times more often that the updated eclass that is the subject of this thread. Therefore, a simple elog entry is a valid handling and fully compliant with the principle of The Simplest Thing That Could Possibly Work. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: libtool problem
Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD: > The reason there wasn't a bump (IIRC) was that the ebuild never changed > - only the eclass did. If you emerged any version of GCC during the > window where the eclass was broken, that version of GCC would have been > broken. That also means that portage is broken. Whenever something changes where other things depend on, those other things should be rebuilt. This doesn't happen here. Bye... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: libtool problem
On Tue, 03 Feb 2009 22:25:34 -0500, ABCD wrote: > The reason there wasn't a bump (IIRC) was that the ebuild never changed > - - only the eclass did. If you emerged any version of GCC during the > window where the eclass was broken, that version of GCC would have been > broken. Of course, I'd forgotten that the change was in the eclass. -- Neil Bothwick I understand the answers, the questions throw me. signature.asc Description: PGP signature
[gentoo-user] Re: libtool problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neil Bothwick wrote: > Mike Kazantsev wrote: > >> And I hate to re-emerge same gcc every time some minor bug (which I >> didn't happen to reproduce) is fixed. > > IKWYM but I think, on balance, this one would have benefited from a bump > as the effects of the breakage were quite widespread. It did make a > difference to the installed files, which is the usual criterion for a > bump. The reason there wasn't a bump (IIRC) was that the ebuild never changed - - only the eclass did. If you emerged any version of GCC during the window where the eclass was broken, that version of GCC would have been broken. - -- ABCD -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmJCq4ACgkQOypDUo0oQOqeqwCgrFG9t4t3+ZmTKY5EcjW81Ab/ YIoAmQEQh7FXNlrIj/dCmqSGoIk+g4YG =3Eiv -END PGP SIGNATURE-
[gentoo-user] Re: libtool problem
Helmut Jarausch wrote: On 3 Feb, Dirk Heinrichs wrote: Am Dienstag, 3. Februar 2009 13:15:55 schrieb Helmut Jarausch: since a short time many (not all) packages fail to build with a message like /bin/sed: can't read /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgomp.la The problem is that I have upgraded to gcc-4.3.3 so there is no path /usr/lib/gcc/i686-pc-linux-gnu/4.3.2 anymore. I have rebuilt libtool, sourced /etc/profile still I cannot get rid of this problem. Did you run "fix_libtool_files.sh 4.3.2"? Thanks! Where does this beast come from? It's also in the official documentation. Chapter "Gentoo GCC Upgrade Guide", section "Frequent Error Messages" :P http://www.gentoo.org/doc/en/gcc-upgrading.xml#doc_chap5
