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 compatible.) > 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 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 package. > 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) Nice! > > > 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.) Yep. > > > 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 <[email protected]> http://NxNW.org/~steve/
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
