Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Aaron W. Swenson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/04/2012 05:26 PM, Pacho Ramos wrote:
> Hello, will send this to gentoo-dev mailing list per Zac's
> suggestion ;):
>
> ...They usually do a good job maintaining them, the only issue I
> see they hit from time to time is forgetting to run JUST AFTER
> updating their systems revdep-rebuild (well, this is so common that
> they usually don't forget to), rebuild
> dbus-glib/gobject-introspection after major glib update, rebuild
> X11 drivers...
>
> This is because, even if all this information is recorded in
> /var/log/portage/elog/summary.log, currently, that log file is
> cluttered of a lot of other elog lines that are not related at all
> with this important task of rebuilding packages. This is why I
> suggested: https://bugs.gentoo.org/show_bug.cgi?id=413619
>
> That would create a new "erebuild" (or whatever the name you
> prefer) to ONLY contain exact command to run by admin to have a
> safe system after update. It would have as main advantage: - Looks
> easier to implement. - It relies in current and existing tools
> (python-updater, perl-cleaner, "q", equery...), then, they could be
> used just now via a script running all of them. - It also looks
> much more "professional" to try to unify a bit what commands to run
> ;) (currently, some ebuilds tells you to manually re-emerge
> packages and some people wrongly run "emerge dbus-glib" when they
> should run "emerge -1 dbus-glib". Telling us to people what exact
> command they need to copy&paste&run will help to get their systems
> cleaner also.
>
> ...
>
> The problem of that one is that, even if it would be "the perfect
> solution": - Looks to be stalled for a long time. - Looks to need a
> lot of functions (like revdep-rebuild, python-updater...) to be
> merged in portage itself. It will then probably take a lot of time
> to get them integrated (specially seeing we are still not able to
> use preserve-libs because it looks to cause some other problems) -
> In that bug report I have also seen discussion about whether
> handle this only via SLOTs (that personally think it will be even
> harder to achieve for all packages in the tree showing this kind of
> problems when updating, for example, I doubt how "glib" -
> "dbus-glib/g-i" case could be handled in this way. - Looks like
> there is no consensus about what to do and, then, this could
> probably be implemented on eapi... 7? While former could probably
> be implemented much sooner (probably even in eapi5)
>
> This is why I think we should try to push a bit my first suggestion
> for the short term until "the perfect one" is ready as, until then,
> we are having for years a problem that, personally, I think it
> should be handled a bit better.
>
> Thanks a lot for your attention
>

"There's never anything important in all that text." - Anonymous
Gentoo User

We've already determined that the users don't read the output. This is
a known fact. Something I repeat in #gentoo more often than I care to
admit is "Seriously, read the output." I agree with the users that
there's too much output, and some of the output is indeed useless.

The output they aren't reading isn't just rebuild commands, but also
the next step they're supposed to take after the emerge has finished,
groups their users need to be in to use a particular feature, et cetera.

The ideal solution is for the Ebuild to instruct the PMS to rebuild
the dependent packages.

We can have a variable called REBUILD. All packages that would need to
be rebuilt can be listed in it. Only those packages that are installed
would be built. The actual list of the packages to be rebuilt would be
determined at dependency checking time. That way, the user can approve
the rebuild of the packages.

Just placing the commands in a separate log won't really solve a whole
lot. Further, it will bump any elog messages even further down in the
importance ranking.

- --
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email    : titanofold@g.o
GnuPG FP : 2C00 7719 4F85 FB07 A49C  0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk/N/xgACgkQVxOqA9G7/aBGGwD/TNRbZNie6J1RkI0DETgcUlwG
VXBY2UamMijjKLFPluEA/jwo9B7qejNkiko/xDvecUq8CaF02Qc4tKMf/MbWs7LW
=ysgF
-----END PGP SIGNATURE-----