Summary: | [PATCH] sys-apps/portage: emerge should warn about invalid values in FEATURES | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Marcin Kryczek <mkay> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | esigra, jacobgodserv |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 326275 | ||
Bug Blocks: | 335925 | ||
Attachments: |
sample config.log
Make emerge warn on unknown values in FEATURES Warn if FEATURES contains unknown values and don't keep them Warn if FEATURES contains unknown values and don't keep them |
Description
Marcin Kryczek
2010-07-02 07:51:14 UTC
Created attachment 237223 [details]
sample config.log
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.4/cc1: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory ^ Upgrading to mpfr-3.0.0 keeps that file, and tells you to run "revdep-rebuild --library libmpfr.so.1". That will recompile GCC, and relink it against the new library from mpfr-3.0.0. It's properly handled in Portage, so closing i don't think we understood each other correctly;) i'm not able to rebuild gcc, since i get 'C compiler cannot create executables' error. also - i do not get any info after upgrading mpfr. here's what i see on console after finishing instalation: >>> Installing (1 of 1) dev-libs/mpfr-3.0.0 >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * Regenerating GNU info directory index... * Processed 153 info files. * IMPORTANT: 2 config files in '/etc' need updating. * See the CONFIGURATION FILES section of the emerge * man page to learn how to update config files. PS: why preserve-libs in FEATURES doesn't help in this situation? i've found a problem - when i turn *off* 'preserve-libs' in FEATURES, this file is preserved and i get a notice. so i think this bug should be reassigned to portage devs - it seems like 'preserve_old_lib' function *disable* 'preserve-libs' in FEATURES for users, who have it turned on (In reply to comment #4) > i've found a problem - when i turn *off* 'preserve-libs' in FEATURES, this file > is preserved and i get a notice. > > so i think this bug should be reassigned to portage devs - it seems like > 'preserve_old_lib' function *disable* 'preserve-libs' in FEATURES for users, > who have it turned on > preserve-libs is a Portage 2.2 feature, not a Portage 2.1 one which you are using... Created attachment 237357 [details]
Make emerge warn on unknown values in FEATURES
Created attachment 237369 [details, diff]
Warn if FEATURES contains unknown values and don't keep them
Created attachment 237379 [details, diff]
Warn if FEATURES contains unknown values and don't keep them
(In reply to comment #8) > Created an attachment (id=237379) [details] > Warn if FEATURES contains unknown values and don't keep them Thanks, this is in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=8f89f480b8b66b1b2254e937406e4b2b92813894 I've added a way to disable the warning here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=fc0e49d98177691813fe81d0ef678bb7192180b3 Just set FEATURES=-unknown-features-warn to disable the warning. We've had a complaint about this warning from ferringb, since pkgcore shares the same config files and supports some FEATURES settings that portage doesn't support. He's suggested adding something like a /etc/portage/valid_features.d/ directory so that pkgcore can install a file to indicate that some other features are exempt from the warning. However, it seems to me that this is getting rather complex for a warning that is of questionable value and was intended to be very simple. I'd prefer to encourage pkgcore users to set FEATURES=-unknown-features-warn than to go with the valid_features.d which seems like over-engineering to me. It's also worth noting that the preserve_old_lib issue that brought this whole thing up could be solved by making preserve_old_lib cease to query FEATURES (as required by PMS), and using a separate environment variable to control preserve_old_lib (as suggested in bug 326275). (In reply to comment #11) > It's also worth noting that the preserve_old_lib issue that brought this whole > thing up could be solved by making preserve_old_lib cease to query FEATURES (as > required by PMS), and using a separate environment variable to control > preserve_old_lib (as suggested in bug 326275). _This_ makes sense to me. If someone writes code that breaks a user's machine because it breaks PMS, it seems logical to immediately rewrite the code in question to obey PMS so it doesn't break anything. This is in 2.2_rc68, but I'll leave this bug open until it's in an unmasked version. This is fixed in 2.1.9. |