On Wed, 2004-04-07 at 14:21, Colin Walters wrote:
> On Wed, 2004-04-07 at 13:30, Jeremy Katz wrote:
>
> > This could be argued for a lot of other things too. It's completely
> > unscalable, though. I'll reference specspo again. Also, it means that
> > whenever something new is added, either
> > a) the person adding the package has to analyze it and then add to the
> > policy package (which they don't own) and make the changes
> > or
>
> They could write a proposed policy and submit a patch. Or just send a
> description of what the program does to a policy editor team, who could
> then write policy.
>
This is not a good solution because of Non-Fedora _Core_ packages.
Sure, Core developers can submit patches to policy and when things get
updated the new policy will go out the door. But third parties (even an
official Fedora Extras) won't have that ability because updates to
packages there won't be able to stay in sync with the policy package.
Someone brought up the libc5 => glibc move as being a comparable
use-case earlier. I'd like to point out that the proceedure for 3rd
party packages in that case was:
1) try rpm --rebuild.
2) If that didn't work, hack source or wait for upstream to hack source.
3) Goto 1
For SELinux, I'd like a similar set of instructions. And also some
discussion as to whether this set of instructions would be reasonably
permanent or just a tide-me-over. It seems like Jeremy's pointing out
some problems with the current policy-package approach and I want to
know if changes to resolve those problems are likely to be major enough
that a new recipe would have to be worked out.
-Toshio "NowToInstallTest2SoICanPutMyMoneyWhereMyMouthIs" Kuratomi
--
_______S________U________B________L________I________M________E_______
t o s h i o + t i k i - l o u n g e . c o m
GA->ME 1999
