[apparmor] 2.8 Nominations

Steve Beattie steve at nxnw.org
Thu Jan 3 18:20:13 UTC 2013

On Thu, Jan 03, 2013 at 12:25:05PM +0100, Christian Boltz wrote:
> Am Mittwoch, 2. Januar 2013 schrieb Steve Beattie:
> > On Wed, Jan 02, 2013 at 04:27:33PM -0800, Steve Beattie wrote:
> > That leaves the following that I nominated for 2.8.1:
> > >   2079 - libapparmor - add pkgconfig support
> Assuming it won't break anything - no objections.
> However I have a packaging question ;-)
> The .spec I'm using contains (for historical reasons[tm] - at least I
> doubt I added it myself)
>     # re-define _libdir to /lib or /lib64
>     %define _libdir /%{_lib}

This is likely a historical artifact. Long, long ago libimmunix
provided a necessary symbol for stackguard, and since everything
in ImmunixOS was recompiled with stackguard, the symbol (and thus
libimmunix) needed to be available on the root filesystem. We then
commingled these libraries, and the assumptions we had carried over
into the packages we generated for OpenSUSE, even though by then gcc
had gained the stack-protector option upstream, and the symbols were
no longer necessary.

[Actually, at this point, the libimmunix bit ought to be dropped
 from the tree entirely (but not for 2.8 :) ).  It has included a
 constructor that emits a deprecation warning message to syslog since
 at least 2008; I think that's been a long enough warning.]

> This means the *.pc file ends up in /lib*/pkgconfig - but all *.pc files 
> typically seem to be in /usr/lib*/pkgconfig/.
> The easiest way to fix this would be not to re-define _libdir. This 
> would also mean the following files would move to /usr/lib*/:
> -rw-r--r-- 1 root root 56862 23. Dez 18:03 /lib64/libapparmor.a
> lrwxrwxrwx 1 root root    20 25. Dez 19:59 /lib64/libapparmor.so -> libapparmor.so.1.0.2
> lrwxrwxrwx 1 root root    20 25. Dez 16:47 /lib64/libapparmor.so.1 -> libapparmor.so.1.0.2
> -rwxr-xr-x 1 root root 47155 23. Dez 18:03 /lib64/libapparmor.so.1.0.2
> -rw-r--r-- 1 root root 12472 23. Dez 18:03 /lib64/libimmunix.a
> lrwxrwxrwx 1 root root    19 25. Dez 19:59 /lib64/libimmunix.so -> libimmunix.so.1.0.2
> lrwxrwxrwx 1 root root    19 25. Dez 16:47 /lib64/libimmunix.so.1 -> libimmunix.so.1.0.2
> -rwxr-xr-x 1 root root 18391 23. Dez 18:03 /lib64/libimmunix.so.1.0.2
> Which side effects would moving those libs cause?

Well, if OpenSUSE is going to require a unified /usr and /, even if
something early in the boot process was linked against libapparmor,
it should still be able to find it in /usr/lib/.

Note that in Ubuntu, we ship libapparmor in /usr/lib and don't include
libimmunix at all. (Hrm, though we probably ought to make it multiarch

> Or is there a way to have the libs in /lib*/ and the *.pc file in /usr/lib*/?

It's an area of autotools that I'm not anywhere near knowledgeable
enough about. It *looks* like you can override the 'pkgconfigdir' make
variable on install to get it to land in the right place, e.g.

  configure --libdir=/lib --prefix=/usr
  make install DESTDIR=/some/temporary/install/location pkgconfigdir=/usr/lib/pkgconfig/

appears to do the right thing. One thing to double check if you do
that is to make sure that the contents of the libapparmor.pc file that
is installed points to the right locations, such that pkg-config(1)
will return the correct information for things that wish to link
against libapparmor.

> If it causes too many problems, I'd prefer to delay it to 3.0.
> (Maybe I'll do an online update to 2.8.1 for openSUSE 12.2 - but only
> if I can use the same package that I also commit to Factory ;-)

Worst case, you could just not include the pkgconfig file in your

> BTW: I have packages with a trunk snapshot in
> https://build.opensuse.org/package/show?package=apparmor&project=home%3Acboltz%3Abranches%3Ahome%3Acboltz
> (not tested yet)


> > > I'm more ambivalent about the following trunk commits. I'm
> > > nominating
> > > them for 2.8, but could be convinced to that they should not be
> > > included:
> > >   2069 - profiles - install extras into
> > >   /usr/share/apparmor/extra-profiles/ 
> I doubt we should do this in a minor release. The extra profiles were in 
> /etc for years, so delaying the move to the 3.0 release won't hurt.
> OTOH, confusing users by moving files around in a minor release _will_ 
> hurt.

Fair enough.

> (But you should of course backport the updated mailinglist address in 
> the extra profiles README, which was part of that commit IIRC.)


> > >   2078 - profiles - add winbindd profile
> I won't strongly object, but introducing a new profile in a bugfix 
> release might not be the best idea. Yes, the profile works on openSUSE
> without problems, but it might still cause problems on other distributions
> (for example, if they use different /var paths for the samba stuff).

That seems a reasonable objection.

> > > Christian, if you'd like to do the merge for the ones you nominated
> > > yourself, that's fine by me, but if you'd rather I do them while I'm
> > > merging my nominations that are acceptable to others, that's cool,
> > > too.
> > This offer still stands.
> Did you really think a lazybone like me will say "no" if someone offers 
> to do the work? ;-)  I'll be happy if you merge all patches ;-)

:-) Great, thanks!

Steve Beattie
<sbeattie at ubuntu.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130103/76b380ff/attachment.pgp>

More information about the AppArmor mailing list