FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-04-2011, 07:35 PM
Sven Vermeulen
 
Default We need *you* for a USE="selinux" dependency

Hi guys 'n gals

obligatory tl;dr:
Please check your package below this list and see if it (the package) has
a proper DEPEND and RDEPEND on the listed sec-policy/selinux-<module> package(s)

Within the Gentoo Hardened project, we are working on getting the SELinux
support into shape. Recent evolutions are the stabilization of latest upstream
userspace utilities and policies as well as documentation improvements and even
some "human resource improvements" (read: fresh blood in our ranks).

Within SELinux, specific modules are used (called SELinux modules, because we
are not that creative in our naming) that contain the SELinux policy (what is
allowed) as well as labeling information for files (which we call file context
information). This labeling is very important in order for the policies to work
well - wrong labels will lead to applications running with wrong permissions
(which usually means "Application No Workie").

In Gentoo, unlike some other distributions, we try to keep the number of
loaded/installed modules to a minimum so that policy rebuilds as well as the
system overhead is limited. This results in a "base" policy (provided by
selinux-base-policy) and modules (provided by sec-policy/selinux-<modulename>). To make
sure that installations of a package pull in the right SELinux module, the
proper dependencies must be defined.

In the list below you will find "package dependency" information. This means
that the given package should have both DEPEND and RDEPEND on the dependency
(which is always of the form sec-policy/selinux-<modulename> since dependencies
on sec-policy/selinux-base-policy are always satisfied the moment a user has SELinux
enabled on his Gentoo system).

The dependency should be USE="selinux"-triggered (the selinux USE flag is masked
for non-SELinux profiles and mandatory on SELinux systems), like so:
IUSE="selinux"
DEPEND="selinux? ( sec-policy/selinux-<modulename> )"
RDEPEND="selinux? ( sec-policy/selinux-<modulename> )"

The dependency must be on both levels, because the SELinux module must be
installed before the package is installed (and in theory, RDEPEND could
trigger an installation afterwards): during the installation phase, Portage
labels the files on the system (which would get wrong labels if the module
isn't installed yet[1]). Also, DEPEND isn't sufficient due to binary package
support requirements.

Since there are quite a few packages that would need updates, I thought about
first mailing gentoo-dev for feedback and perhaps a first chunk of work done. I
also wouldn't mind creating bugreports for each of them, but that would still be
best done after having mailed gentoo-dev ;-)

Wkr,
Sven Vermeulen

[1] I am aware that Portage currently installs RDEPEND before the package
itself, but that might change in the future and other package managers might
exhibit different behavior.

games-board/aisleriot sec-policy/selinux-games
sys-apps/apmd sec-policy/selinux-apm
net-dns/bind sec-policy/selinux-bind
net-wireless/bluez sec-policy/selinux-bluetooth
app-i18n/canna sec-policy/selinux-canna
app-cdr/cdrkit sec-policy/selinux-cdrecord
app-cdr/cdrtools sec-policy/selinux-cdrecord
app-antivirus/clamav sec-policy/selinux-clamav
net-im/climm sec-policy/selinux-games
mail-mta/courier sec-policy/selinux-courier
net-print/cups sec-policy/selinux-lpd
dev-vcs/cvs sec-policy/selinux-cvs
sys-process/daemontools sec-policy/selinux-daemontools
sys-process/daemontools-encore sec-policy/selinux-daemontools
mail-filter/dcc sec-policy/selinux-dcc
app-admin/denyhosts sec-policy/selinux-denyhosts
sys-devel/distcc sec-policy/selinux-distcc
net-dns/djbdns sec-policy/selinux-djbdns
app-arch/dpkg sec-policy/selinux-dpkg
app-cdr/dvd+rw-tools sec-policy/selinux-cdrecord
www-client/epiphany sec-policy/selinux-mozilla
x11-misc/expocity sec-policy/selinux-wm
net-analyzer/fail2ban sec-policy/selinux-fail2ban
app-arch/fastjar sec-policy/selinux-java
net-mail/fetchmail sec-policy/selinux-fetchmail
www-client/firefox-bin sec-policy/selinux-mozilla
dev-java/gcj-jdk sec-policy/selinux-java
dev-vcs/gitolite sec-policy/selinux-gitosis
dev-vcs/gitolite-gentoo sec-policy/selinux-gitosis
dev-vcs/gitosis sec-policy/selinux-gitosis
dev-vcs/gitosis-gentoo sec-policy/selinux-gitosis
virtual/gnat sec-policy/selinux-ada
gnome-base/gnome-applets sec-policy/selinux-cpufreqselector
gnome-extra/gnome-games sec-policy/selinux-games
gnome-base/gnome-shell sec-policy/selinux-wm
app-crypt/gnupg sec-policy/selinux-gpg
www-servers/gorg sec-policy/selinux-gorg
gpe-base/gpe-dm sec-policy/selinux-xserver
net-print/hplip sec-policy/selinux-cups
x11-apps/iceauth sec-policy/selinux-xserver
net-misc/icecast sec-policy/selinux-icecast
net-nntp/inn sec-policy/selinux-inn
kde-base/katomic sec-policy/selinux-games
kde-base/kbattleship sec-policy/selinux-games
sys-apps/kbd sec-policy/selinux-loadkeys
kde-base/kblackbox sec-policy/selinux-games
kde-base/kbounce sec-policy/selinux-games
kde-base/kgoldrunner sec-policy/selinux-games
kde-base/kgpg sec-policy/selinux-gpg
net-wireless/kismet sec-policy/selinux-kismet
kde-base/kjumpingcube sec-policy/selinux-games
kde-base/klickety sec-policy/selinux-games
kde-base/klines sec-policy/selinux-games
kde-base/kmahjongg sec-policy/selinux-games
kde-base/kmines sec-policy/selinux-games
kde-base/kolf sec-policy/selinux-games
kde-base/konquest sec-policy/selinux-games
kde-base/kpat sec-policy/selinux-games
kde-base/kreversi sec-policy/selinux-games
kde-base/kshisen sec-policy/selinux-games
kde-base/kspaceduel sec-policy/selinux-games
kde-base/ktron sec-policy/selinux-games
kde-base/ktuberling sec-policy/selinux-games
app-emulation/libvirt sec-policy/selinux-xen
www-client/links sec-policy/selinux-links
kde-base/lskat sec-policy/selinux-games
dev-db/mariadb sec-policy/selinux-mysql
net-misc/memcached sec-policy/selinux-memcached
x11-wm/metacity sec-policy/selinux-wm
sys-apps/mlocate sec-policy/selinux-slocate
www-servers/mongrel sec-policy/selinux-apache
media-sound/mpd sec-policy/selinux-mpd
sys-cluster/mpich2 sec-policy/selinux-mpd
media-video/mplayer sec-policy/selinux-mplayer
media-video/mplayer2 sec-policy/selinux-mplayer
net-analyzer/mrtg sec-policy/selinux-mrtg
mail-client/mutt sec-policy/selinux-mutt
dev-db/mysql sec-policy/selinux-mysql
media-libs/nas sec-policy/selinux-soundserver
net-misc/netcf sec-policy/selinux-ncftool
net-ftp/netkit-ftpd sec-policy/selinux-publicfile
mail-mta/netqmail sec-policy/selinux-qmail
net-analyzer/ntop sec-policy/selinux-ntop
net-misc/nxserver-freeedition sec-policy/selinux-nx
net-misc/nxserver-freenx sec-policy/selinux-nx
x11-wm/openbox sec-policy/selinux-wm
net-misc/openconnect sec-policy/selinux-vpn
net-nntp/pan sec-policy/selinux-pan
sys-boot/plymouth sec-policy/selinux-plymouthd
app-admin/prelude-lml sec-policy/selinux-prelude
app-admin/prelude-manager sec-policy/selinux-prelude
mail-filter/procmail sec-policy/selinux-procmail
net-ftp/proftpd sec-policy/selinux-ftp
www-servers/publicfile sec-policy/selinux-publicfile
media-sound/pulseaudio sec-policy/selinux-pulseaudio
app-admin/puppet sec-policy/selinux-puppet
dev-python/pyzor sec-policy/selinux-pyzor
app-emulation/qemu sec-policy/selinux-qemu
app-emulation/qemu-kvm sec-policy/selinux-qemu
www-apps/roundup sec-policy/selinux-roundup
app-arch/rpm sec-policy/selinux-rpm
app-shells/rssh sec-policy/selinux-rssh
net-fs/samba sec-policy/selinux-samba
app-misc/screen sec-policy/selinux-screen
net-mail/serialmail sec-policy/selinux-daemontools
net-im/skype sec-policy/selinux-skype
net-nntp/slrn sec-policy/selinux-slrnpull
mail-filter/spamassassin sec-policy/selinux-spamassassin
net-misc/stunnel sec-policy/selinux-stunnel
net-nntp/suck sec-policy/selinux-inn
net-misc/taylor-uucp sec-policy/selinux-uucp
media-sound/timidity++ sec-policy/selinux-timidity
net-irc/tirc sec-policy/selinux-irc
net-misc/tor sec-policy/selinux-tor
media-tv/tvtime sec-policy/selinux-tvtime
x11-wm/twm sec-policy/selinux-wm
sys-apps/ucspi-tcp sec-policy/selinux-ucspitcp
sys-apps/usermode-utilities sec-policy/selinux-uml
www-servers/varnish sec-policy/selinux-varnishd
net-misc/vde sec-policy/selinux-vde
media-video/vlc sec-policy/selinux-mplayer
app-emulation/vmware-workstation sec-policy/selinux-vmware
net-analyzer/vnstat sec-policy/selinux-vnstatd
app-admin/webalizer sec-policy/selinux-webalizer
app-emulation/wine sec-policy/selinux-wine
net-analyzer/wireshark sec-policy/selinux-wireshark
net-wireless/wpa_supplicant sec-policy/selinux-networkmanager
x11-apps/xauth sec-policy/selinux-xserver
media-video/xine-ui sec-policy/selinux-mplayer
x11-base/xorg-server sec-policy/selinux-xprint
x11-base/xorg-server sec-policy/selinux-xprint
x11-misc/xscreensaver sec-policy/selinux-xscreensaver
sys-apps/yum sec-policy/selinux-rpm
 
Old 12-04-2011, 07:50 PM
Petteri Räty
 
Default We need *you* for a USE="selinux" dependency

On 04.12.2011 22:35, Sven Vermeulen wrote:
> Hi guys 'n gals
>
> obligatory tl;dr:
> Please check your package below this list and see if it (the package) has
> a proper DEPEND and RDEPEND on the listed sec-policy/selinux-<module> package(s)
>

The list would be easier to read if it was sorted. Also it should be
quite easy to check automatically that the atoms in place.

Regards,
Petteri
 
Old 12-04-2011, 09:10 PM
Fabio Erculiani
 
Default We need *you* for a USE="selinux" dependency

On Sun, Dec 4, 2011 at 9:35 PM, Sven Vermeulen <swift@gentoo.org> wrote:
> [...]
> The dependency must be on both levels, because the SELinux module must be
> installed before the package is installed (and in theory, RDEPEND could
> trigger an installation afterwards): during the installation phase, Portage
> labels the files on the system (which would get wrong labels if the module
> isn't installed yet[1]). Also, DEPEND isn't sufficient due to binary package
> support requirements.
>
>
> Wkr,
> * * * *Sven Vermeulen
>
> [1] I am aware that Portage currently installs RDEPEND before the package
> * *itself, but that might change in the future and other package managers might
> * *exhibit different behavior.
>

I haven't really understood what you mean with RDEPENDs being scheduled "after".
RDEPEND must be always scheduled before the pkg requiring it, changing
this behaviour would have disruptive effects on all the PMS out there
(OTOH I think I haven't gotten the point actually?). I guess portage
may schedule it in arbitrary order if the RDEPEND dep itself is
satisfied already (this would mean that you explicitly pulled it in),
and this is the only case I can think of.
If you need to schedule a dep install at some point, you should rather
use PDEPEND, but if the same is required earlier in the schedule,
well, you're flooked.

--
Fabio Erculiani
http://lxnay.com
 
Old 12-04-2011, 09:53 PM
Mike Frysinger
 
Default We need *you* for a USE="selinux" dependency

On Sunday 04 December 2011 15:35:50 Sven Vermeulen wrote:
> Since there are quite a few packages that would need updates, I thought
> about first mailing gentoo-dev for feedback and perhaps a first chunk of
> work done. I also wouldn't mind creating bugreports for each of them, but
> that would still be best done after having mailed gentoo-dev ;-)

i generally don't want to see bug reports that say "please add IUSE=selinux to
XXX package and add 'selinux? ( sec-policy/selinux-XXX )' to *DEPEND". if
selinux wants policies pulled in by packages based on USE=selinux, and that's
the only change needed, then feel free to commit the change yourself for any
toolchain / base-system / vapier package. probably easiest to skip the
revbump and just commit to existing packages since selinux has been deadish
for quite sometime :P.

> games-board/aisleriot sec-policy/selinux-games

i don't see why this game is singled out. if you have a selinux policy for
all games, then it sounds like we should add this logic to games.eclass.

> net-im/climm sec-policy/selinux-games

you sure about that one ? this isn't a game (unless you count all forms of IM
a "game" ).

and yes, this list really really should have been sent through `sort`
-mike
 
Old 12-05-2011, 02:04 AM
Brian Harring
 
Default We need *you* for a USE="selinux" dependency

On Sun, Dec 04, 2011 at 11:10:17PM +0100, Fabio Erculiani wrote:
> On Sun, Dec 4, 2011 at 9:35 PM, Sven Vermeulen <swift@gentoo.org> wrote:
> > [...]
> > The dependency must be on both levels, because the SELinux module must be
> > installed before the package is installed (and in theory, RDEPEND could
> > trigger an installation afterwards): during the installation phase, Portage
> > labels the files on the system (which would get wrong labels if the module
> > isn't installed yet[1]). Also, DEPEND isn't sufficient due to binary package
> > support requirements.
> >
> >
> > Wkr,
> > ?? ?? ?? ??Sven Vermeulen
> >
> > [1] I am aware that Portage currently installs RDEPEND before the package
> > ?? ??itself, but that might change in the future and other package managers might
> > ?? ??exhibit different behavior.
> >
>
> I haven't really understood what you mean with RDEPENDs being scheduled "after".
> RDEPEND must be always scheduled before the pkg requiring it,

While it appears that way, it's not actually true; RDEPEND is what the
pkg requires to be able to be usable, not what is required to merge
it.

Key thing there is the 'run' part; the manager can merge a pkg that
isn't yet usable (unsatisfied rdeps), as long as nothing in the graph
currently requires the pkg to be working at that state in the build
plan.

Assuming pkg x DEPENDs on a, and RDEPENDS on b for the context of this
discussion, it's perfectly valid for the manager to sequentially build
and merge (a, x, b). At the point 'b' is merged, 'x' is considered
satisfied/usable.

This is the long term rules; the reason it's not obvious is because
it's rare for the graph to be flexed in such a fashion that a,x,b is
forced rather than a,b,x. Cycles, blockers, odd deps, etc, can
force it however.


> If you need to schedule a dep install at some point, you should rather
> use PDEPEND, but if the same is required earlier in the schedule,
> well, you're flooked.

In the context of this discussion (apply selinux policies), PDEPEND
isn't valid; PDEPEND should be used strictly for for deps that are
RDEPEND required, but the pkg can function (degraded) without; this
being done for cycle breaking reasons. Well aware people don't always
abide by those terms, but that's the actual rules.

Selinux wise, the policy needs to be available for applying at merge
time, so PDEPEND doesn't fly.
~harring
 
Old 12-05-2011, 02:10 AM
Rich Freeman
 
Default We need *you* for a USE="selinux" dependency

On Sun, Dec 4, 2011 at 5:10 PM, Fabio Erculiani <lxnay@gentoo.org> wrote:
> I haven't really understood what you mean with RDEPENDs being scheduled "after".
> RDEPEND must be always scheduled before the pkg requiring it, changing
> this behaviour would have disruptive effects on all the PMS out there

There is only one PMS out there, unless you're counting versions (they
are cumulative so the latest approved one should be the one you use -
correct me if I'm wrong there). PMS != package manager.

In this particular case the approved PMS says "In the pkg phases, at
least one of the following conditions must be met: any command
provided by a packaged listed in DEPEND is available; any command
provided by a packaged listed in RDEPEND is available." Perhaps
somebody with a more twisted sense of logic than I can make some sense
out of that - to me it suggests that an ebuild can safely assume that
either the packages listed in DEPEND are available, or the packages
listed in RDEPEND are available, but not necessarily both (though you
could count on RDEPEND if you have DEPEND=RDEPEND set or are using an
EAPI that has this behavior).

I suspect that the PMS team has already noticed that since the current
non-approved PMS is a bit more clear. It says (in a table) that any
of the pkg phases can assume that the RDEPENDs are there "(unless the
particular dependency results in a circular dependency, in which case
it may be installed later)." I guess that means that pkg phases can't
assume that RDEPENDs are there after all. Additionally pkg_config can
assume that RDEPEND and PDEPEND are present (with no caveats). None
of the pkg phases can assume that anything in DEPEND is present
(obviously unless it is also in RDEPEND).

My sense is that none of the PMS versions really say quite what we
want the behavior to be - as to be truly compliant ebuilds would have
to require nothing outside of the base system in the pkg phases (other
than pkg_config) - then again, maybe we can live with that. It
doesn't seem to add much value to say that RDEPEND /might/ be
available - the necessary conditional logic to take advantage of a
command that might or might not be present seems like a QA nightmare.
We should probably specify that ebuilds either can safely count on
RDEPEND, or not, in each of the phases.

(Disclaimer - I claim no special knowledge of the mechanics of your
favorite package manager - I'm simply reading the specs.)

Rich
 
Old 12-05-2011, 06:27 AM
Duncan
 
Default We need *you* for a USE="selinux" dependency

Rich Freeman posted on Sun, 04 Dec 2011 22:10:19 -0500 as excerpted:

> My sense is that none of the PMS versions really say quite what we want
> the behavior to be - as to be truly compliant ebuilds would have to
> require nothing outside of the base system in the pkg phases (other than
> pkg_config) - then again, maybe we can live with that. It doesn't seem
> to add much value to say that RDEPEND /might/ be available - the
> necessary conditional logic to take advantage of a command that might or
> might not be present seems like a QA nightmare. We should probably
> specify that ebuilds either can safely count on RDEPEND, or not, in each
> of the phases.

tl;dr folks can skip. This is just an explanation for those who might
need it, tho the usual disclaimers about not being a PM or PMS guru
apply, so assuming I've got it straight, myself.

You are, I believe, correct as to the pkg phase requirements -- other
than pkg_config, they actually require nothing other than @system. The
second-to-last paragraph has the solution already proposed by the PM/PMS
folks, but there's some resistance, reasons explained there.

It helps to keep in mind the situation with 100% binpkg installations
that do no building, along with RDEPEND's cycle-breaking role. Obviously
DEPEND can't be counted on there since such systems do no building.
Equally obviously, RDEPEND must eventually be installed for full runtime
functionality, but can't be depended on during the pkg phases so as to
fill the circular dependency requirements.

The distinction between PDEPEND and RDEPEND, then, is that PDEPEND is
more like a strong recommendation, it should be installed as well, but
the package doesn't depend on it to actually run so installation can be
put off more or less indefinitely, while RDEPEND is assumed to be there
as soon as the package is installed, since at that point it's assumed to
be runnable and RDEPEND is runtime dependencies. So RDEPEND can't be
depended upon during installation (both src and pkg phases, other than
pkg_config but like PDEPEND, that can be put off indefinitely, from the
PM's and thus PMS perspective), but IS depended upon IMMEDIATELY AFTER
installation, as the package is then considered runnable and thus RDEPEND
must be installed, while PDEPEND installation can be put off effectively
indefinitely.

In practice, because a package is assumed to be runnable as soon as it is
fully installed, RDEPEND is NORMALLY installed first and thus there for
most or all phases, as that's the easiest way to ensure that the package
is fully runnable after the PM is done with that package, but that's not
REQUIRED to be the case, and in a circular dependency bind, a PM MAY have
to wait until after all installation phases are complete, then pause
before actually certifying it so and install the RDEPEND then.

As a paused install, the PM can then fudge the dependencies of the
circularly dependent package since the paused install /is/ actually
installed, all installation phases complete, it's just waiting on that
circular dependency RDEPEND to take the installation off pause and
certify it as fully installed.

For build-systems, putting a package in both DEPEND and RDEPEND thus in
practice assures that it's installed during pkg_preinst and pkg_postinst,
since the PM isn't likely to install it for building, then uninstall it,
then ensure that it's installed after installation at runtime again, but
that doesn't work on 100% binpkg installations either, since they don't
have to consider DEPEND at all because the package isn't being built.

This corner-case is why Ciaran and others involved with the PMs and PMS
have recommended adding additional dependency types, among them, one that
would be required during the post-build install phases (pkg_preinst and
pkg_postinst). That recommendation hasn't gone anywhere, however,
because in most cases the existing deps are "good enough", and at some
point, there's simply too many *DEPEND types to effectively keep track
of, such that the additional costs aren't considered worth the trouble of
the corner-case solution.

I suppose that corner-case might be one reason I occasionally have
installation failures on big updates such as kde, but with --keep-going,
portage continues to install other packages, and at some point manually
retrying the failed installation "just works". The other reason (other
than the occasional job token miscount, -j* issue when multiple merges
are going on, or other apparently random build-system failure) is of
course incompletely specified deps in the dependency thicket of upstream
kde's monolithic tarball buildsystem, but I can't fault gentoo/kde for
missing something there occasionally, particularly when it's not
reproducible afterward because the ordering has been resolved!

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 12-05-2011, 06:54 AM
"Paweł Hajdan, Jr."
 
Default We need *you* for a USE="selinux" dependency

On 12/4/11 9:35 PM, Sven Vermeulen wrote:
> Within the Gentoo Hardened project, we are working on getting the SELinux
> support into shape. Recent evolutions are the stabilization of latest upstream
> userspace utilities and policies as well as documentation improvements and even
> some "human resource improvements" (read: fresh blood in our ranks).

This is excellent progress! Kudos for working on this.

> In Gentoo, unlike some other distributions, we try to keep the number of
> loaded/installed modules to a minimum so that policy rebuilds as well as the
> system overhead is limited. This results in a "base" policy (provided by
> selinux-base-policy) and modules (provided by sec-policy/selinux-<modulename>). To make
> sure that installations of a package pull in the right SELinux module, the
> proper dependencies must be defined.

Are you sure this is right choice? It seems to me that it'd be better to
focus no making things work, and increasing the complexity of the deps
makes this harder (and increasing the number of packages you maintain
too). Unless you have _abundant_ resources to deal with that, I'd like
to discourage you from handling policies that way.

Furthermore, imagine I'm adding a new package "foo" that is covered by
the SELinux policy. Most developers don't use SELinux (hey, I suspect
most of them don't even use developer profile; bad, bad!). How do I know
whether it's sec-policy/selinux-foo that's not yet added or
sec-policy/selinux-games or something else... If the complete policy is
in one package, this should be obvious, and we don't even need deps for
that.

> Since there are quite a few packages that would need updates, I thought about
> first mailing gentoo-dev for feedback and perhaps a first chunk of work done. I
> also wouldn't mind creating bugreports for each of them, but that would still be
> best done after having mailed gentoo-dev ;-)

As said by other devs here, I also think it'd be more effective if you
just do the change yourself. USE="selinux" doesn't affect anything else
so it's safe.
 
Old 12-05-2011, 10:19 AM
Pacho Ramos
 
Default We need *you* for a USE="selinux" dependency

El dom, 04-12-2011 a las 17:53 -0500, Mike Frysinger escribió:
> On Sunday 04 December 2011 15:35:50 Sven Vermeulen wrote:
> > Since there are quite a few packages that would need updates, I thought
> > about first mailing gentoo-dev for feedback and perhaps a first chunk of
> > work done. I also wouldn't mind creating bugreports for each of them, but
> > that would still be best done after having mailed gentoo-dev ;-)
>
> i generally don't want to see bug reports that say "please add IUSE=selinux to
> XXX package and add 'selinux? ( sec-policy/selinux-XXX )' to *DEPEND". if
> selinux wants policies pulled in by packages based on USE=selinux, and that's
> the only change needed, then feel free to commit the change yourself for any
> toolchain / base-system / vapier package. probably easiest to skip the
> revbump and just commit to existing packages since selinux has been deadish
> for quite sometime :P.

I fully agree with Mike here, feel free to change it in packages
maintained by me (I have seen bluez )

>
> > games-board/aisleriot sec-policy/selinux-games
>
> i don't see why this game is singled out. if you have a selinux policy for
> all games, then it sounds like we should add this logic to games.eclass.
>
> > net-im/climm sec-policy/selinux-games
>
> you sure about that one ? this isn't a game (unless you count all forms of IM
> a "game" ).
>
> and yes, this list really really should have been sent through `sort`
> -mike
 
Old 12-05-2011, 11:22 AM
Ciaran McCreesh
 
Default We need *you* for a USE="selinux" dependency

On Sun, 4 Dec 2011 22:10:19 -0500
Rich Freeman <rich0@gentoo.org> wrote:
> In this particular case the approved PMS says "In the pkg phases, at
> least one of the following conditions must be met: any command
> provided by a packaged listed in DEPEND is available; any command
> provided by a packaged listed in RDEPEND is available."

Yeah, that's a screwup that's been discussed at length. It shouldn't be
giving you any guarantees at all for pkg_*, since RDEPEND-RDEPEND
cycles need to be breakable (there are lots of them in the tree).

The fix is likely going to be an IDEPEND or something along those lines
in the next EAPI.

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 02:58 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org