On 6/10/11 6:33 PM, Jeff Johnson wrote: > > On Jun 10, 2011, at 4:39 PM, Mark Hatle wrote: > >> I've been trying to reconcile the behavior between rpm and deb packages in >> the >> way their directories are handled. >> >> In rpm, we can set the directories to "own" in various ways. If there is a >> conflict between two packages owning the same directory -- first-in wins and >> that's where the permissions/owner/group are selected. (correct me if I'm >> wrong) >> > > That's likely (but based on ancient memories of a performance speed-up > to avoid creating already existent directories ... not that mkdir is slow, > just > that is what was originally implemented like 1997). > > But that explains first rather than last. I could look at the code: so can you > rpm -Uvv --fsmdebug *.rpm > should spew every system call performed. > > >> In deb, directories are not owned by any package, they're just created as an >> artifact of the package installation. All of the packages in the system are >> expected to have directories with the same permissions, owners, group or the >> package is broken. I assume this means a similar first-in wins strategy as >> well. >> >> Is there a way in RPM to change this strategy to create a true conflict >> (install >> failure) to identify these situations? >> > > There's no configurable way ... but changing opens a walloping amount > of pain because RPM will *again* have to justify its reliability if > change occurs.
I was wondering because we could optionally enable it as a form of QA. Otherwise we'll have to dump the data from the RPM packages and externally run QA... > I plain and simply don't give a hoot unless a sound > engineering reason is given for the change. > > Change for the sake of change isn't a sound reason, nor is consistency with > the Debian Borg mind meld, nor is introducing Yet Another Way That RPM > Doesn't Install Anything because of lack of vendor QA. > >> Also, what is the impact to RPM if a lot of packages all own the same >> directories (such as /bin, /lib, /usr, etc..)? [or alternatively have no >> packages own the directories and fix the owner/group/mode with some type of >> scripting] > > Lemme answer a question with a question: > > Why are you asking? Are you seeing "impact" or just enquiring? More inquiring at this point... This all stems from two issues that I have to solve. The first is pragmatic, we had a package that was incorrectly creating the /var/lib portion of a directory as 0700, it just happened it was being installed before the base-files package (which normally creates those directories as 0755...) It caused a number of minor problems that took a while to identify. In the Debian world the folks I asked basically said "this doesn't happen".. I asked how they were sure and they spouted some stuff that IMHO really means "cause we treat it as a bug and fix it", well duh.. In the RPM world, I would have solved the issue different, I would have owned the directory and files within the /var/lib, but not /var/lib itself -- that would have been owned by the base-files package.... > Owning all directories in every package so that > rpm -qa | wc -l > and > rpm -qf / | wc -l > are identical is what I think should be done on even days of the month. Currently I'm leaning toward having to have all packages own all files and directories, in order to match the "deb" behavior -- I don't see a reason why this isn't possible, just not what I'm used to doing. My concern with this approach was performance, dependency issues, etc.. (I'm not sure the ramifications of a package owning all of it's directories, as I've never implemented a system that was meant to be that way.) > On odd days of the month, I tend towards the schizoid alterantive POV, that > no directory should be in "packages". > > And on leap days I use dpkg ... ;) I try to avoid it, unless I don't have a choice.. >> >> Any help understanding RPM's behavior in these conditions performance or >> otherwise will help me figure out how to reconcile the behaviors.. thanks! >> > > Everything that rpm does while installing is displayable with > > rpm -Uvv --fsmdebug *.rpm > > Any "quirks" aren't from the state machine, but rather from foolish > fiddle ups for "unowned directory" behavior w SELinux and other insanities. Ya, I figured RPM isn't at fault... I just need a way to reconcile the behavior of RPM, dpkg, opkg and the OpenEmbedded build environment. This is new territory for me. My current thinking is to add some QA and helper routines into OpenEmbedded to ensure that the core "base" set of directories are always correct and matching.. The QA routines would somehow check the directories owned by all of the binary packages and ensure they don't conflict... (as well as don't collide with the preset list from the helper) --Mark ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
