On Jun 10, 2011, at 11:25 PM, Mark Hatle wrote: > > 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… >
OK better QA is the goaal.
The choices are
QA by failing/correcting builds
QA by failing/correcting installs
To do "build QA" (which poky/yacto is well prepared for
with "solvedbs" that can be fed back to the build system)
What is the "everything" universe of package metadata?
to detect (your problem) multiple packages that contain a directory with
different permissions.
If there is a "reference" rpmdb available during build, then problems
can be detected or corrected: with permissions a principle of least/most
access isn't hard to implement with existing data.
There's the additional workflow issue determining when the "reference"
rpmdb is updated:
every successful build?
every successful image creation?
every successful "release"?
and the usually implementation language: python! perl! ruby! bash! cacophony.
A "reference" rpmdb is the right approach imho because all metadata is captured
and available as early as possible, where its rather easy to fix.
There is another approach that can be attempted with additional assertion
checks like
No directory should have 700 permissions.
You can already do this by configuring additional scriptie to be run at end of
%install.
Its unclear which is harder to maintain:
A reference rpmdb and implementations in RPM.
or
Opaque hooks that can be populated as needed to do whatever.
Since "opaque hooks" has been around since forever and still being discussed,
well,
I'd try an "everything" rpmdb to ensure modes set correctly and (more
importantly imho)
no "file conflicts" on path and no "orphan directories".
For "install QA" its largely introducing Yet Another Failure Mode
for client installs, with all the usual
RPM sux because it won't install my packages
support issues. One could of course implement a correction
to directory permission problems based on least/most access,
but then another decade of discussion ensues on Newer! Better! Bestest!
so I'd rather _NOT_ see QA attempted during install's simply because
nooone wishes to write the scriptie for "opaque hooking" or wishes
responsibility for maintaining the "everything" solved so that
problems could be detected during build.
Yes poky/yacto doesn't use rpmbuild for building, but does use *.spec
templates for creating packages, which is where "build QA" would
occur, possibly inconveniently for your workflow.
>> 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.
>
Hmmm … rpm -Va should have detected the permission change on the directory
contained
in multiple packages easily.
The "out-of-order" indeterminacy (which is likely a nasty Heisenbug with no
reproducer)
could be mitigated if you started relying on parent directory dependencies (but
then
you have to pay attention to LOOP's to fully remove the indeterminacy).
> 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..
>
Yes the mind meld has very strong administratively based quality control and
RPM doesn't.
> 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.
>
It would not be hard to add rpmbuild --include-all-directory-paths-always
option.
> 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.)
>
The issues won't be performance related, but rather with the "fuzziness" of say
Provides: /etc/whatever/
and with the lack of a clear and unambiguous convention regarding package
ownership of directories.
If anything, a lot of creepy RPM code could be ripped out if there were clear
convention(s) for packages owning directories, there's all sorts of bubble
gum and band-aids implemented to meet expectations (i.e. close the whiner's bug)
that has been retrofitted, often ad hoc.
I.e. performance would actually improve with clarity on dir owner conventions.
>> 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.
>
The expectation (and one of the "meet expectations to slam the bug report"
hack-o-rounds)
is what RPM has to do to attach SELinux policy to directories that are NOT in
*.rpm
and noone cares to put the directories into SOME package.
> 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)
>
There's several Fts(3) tree walks in RPM. What SHOULD be done is to write a DSL
for some simple assertion based language (and with embedded everything its quite
feasible to support all possible scrip tie writers) that walls a tree once, then
selects which of the DSL rules apply to a specific path, finally run the set
of rule checks that apply to that specific path, collecting
errors/progress/whatever.
But there's always "opaque hooks" that can be run however and whenever you wish.
hth
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
