>> No, I was not thinking of reboot/RPM changing anything already >> installed. I was referring to DB solution as static because >> it would stick one configuration forever. Instead, I was >> thinking of RPM to always base its decision on the environment >> where it is running at that point of time and provide a way >> to override RPM behavior so that advanced users can make a >> choice. > > This is the logic windows installers use but I don't think it's the > correct one. The installer should never change behaviour based on a system > state that can change over time (unless this state is under its control > which is not the case here) I think of this like two categories of machine: 1. Systems that will not change the environment for a very long time and continue to run in either a physical or a virtual environment. 2. Systems that will change the runtime environment occasionally. DB approach works for #1 and fails miserably for #2 (example below). At the same time runtime detection approach works for #1 and works almost right for #2 with few exceptions. Exceptions can be addressed through an override switch. Example: Fedora image running in 'X' virtual environment is moved to 'Y' virtual environment. If 'X' is sticking in the RPM DB, packages intended for 'Y' can't be installed because RPM DB thinks otherwise. Thanks, Ravindra -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
