From: "Lucian Poston" <lucianposton@gmail.com>
To: gentoo-soc@lists.gentoo.org
Cc: "Marius Mauch" <google-soc@genone.de>
Subject: [gentoo-soc] Progress Report - Revdep-rebuild
Date: Sun, 27 Jul 2008 01:28:10 -0500 [thread overview]
Message-ID: <c4cdc1420807262328q5dddf425n261b4bf23767b5a0@mail.gmail.com> (raw)
An option was added to the missing-rebuild set to allow a user to
emerge the set of packages containing consumers of specified
libraries, similar to the revdep-rebuild --library flag. Since flags
can't currently be passed to packages sets through the portage cli,
the user must set the environment variable LIBRARY to the library's
name or a regular expression to match libraries in order to invoke
this functionality.
A couple bugs related to broken or missing symlinks to libraries were
fixed. There is one known bug remaining related to symlinks, which
was introduced as a result of other fixes. Basically, if a target of
a symlink points to a library that does not provide the soname (for
example, /usr/lib/libfoo.so -> libnotfoo.so), binaries that require
/usr/lib/libfoo.so would be potentially broken and ignored. The fix
that I have in mind is to check the target's soname entry in
LinkageMap._obj_properties; however, fixing it will result in
unnecessary packages in the package set (due to libraries missing an
SONAME in it's NEEDED.ELF.2 entry eg libmix.so). Anyway, I figure it
would be better to have false positives than overlooking potential
broken dependencies.
The MissingLibraryConsumerSet.load method was split into 3 smaller
methods to which I've added docstrings conforming to the Portage
Docstring Spec, which only recently came to attention unfortunately.
The code is hopefully easier to digest now.
I never liked the idea of depending on the masks in
/etc/revdep-rebuild/* to remove false positives, so this week I'll try
a different approach in which binaries not found in PATH or library
directories will be ignored. This should reduce the need for
directory and library masks (or more unlikely remove it entirely).
Although, I suspect that this will miss some broken dependencies, so
I'll have a good bit of testing to do.
Lucian
next reply other threads:[~2008-07-27 6:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-27 6:28 Lucian Poston [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-08-21 3:09 [gentoo-soc] Progress Report - Revdep-rebuild Lucian Poston
2008-08-21 15:47 ` Donnie Berkholz
2008-08-21 18:09 ` Lucian Poston
2008-08-11 23:12 Lucian Poston
2008-08-01 21:24 Lucian Poston
2008-07-20 9:23 Lucian Poston
2008-07-12 3:13 Lucian Poston
2008-06-26 1:30 Lucian Poston
2008-06-26 17:47 ` Marius Mauch
2008-06-15 3:55 Lucian Poston
2008-06-17 15:55 ` Marius Mauch
2008-06-15 3:34 Lucian Poston
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c4cdc1420807262328q5dddf425n261b4bf23767b5a0@mail.gmail.com \
--to=lucianposton@gmail.com \
--cc=gentoo-soc@lists.gentoo.org \
--cc=google-soc@genone.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox