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 08-13-2012, 04:55 PM
Samuli Suominen
 
Default FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/targets/developer/make.defaults?r1=1.11&r2=1.12

For example (these are all where they belong):

$ file /usr/lib/udisks2/udisksd
/usr/lib/udisks2/udisksd: ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped


$ file /usr/lib/udev/* |grep ELF
/usr/lib/udev/accelerometer: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/ata_id: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/cdrom_id: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/collect: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/hid2hci: ELF 64-bit LSB shared object,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/ift-load: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/ipod-set-info: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/keymap: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/mtd_probe: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/mtp-probe: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/scsi_id: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/udev-configure-printer: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/udisks-dm-export: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/udisks-lvm-pv-export: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/udisks-part-id: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/udisks-probe-ata-smart: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/udisks-probe-sas-expander: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped
/usr/lib/udev/v4l_id: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.9, stripped


I propably won't be working on this much, so help would be appericiated
for restoring working multilib-strict check.


Thanks, Samuli
 
Old 08-13-2012, 06:14 PM
Diego Elio Pettenò
 
Default FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

On 13/08/2012 09:55, Samuli Suominen wrote:
>
> I propably won't be working on this much, so help would be appericiated
> for restoring working multilib-strict check.

Beside the fact that these would probably have looked better in
/usr/libexec — there used to be a whitelist of stuff that can be
installed in /usr/lib, can't you just add udev and udisks to that list?

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
 
Old 08-13-2012, 06:25 PM
"Rick "Zero_Chaos" Farina"
 
Default FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/13/2012 12:55 PM, Samuli Suominen wrote:
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/targets/developer/make.defaults?r1=1.11&r2=1.12
>
>
> For example (these are all where they belong):

I know it seems silly but there are already so many multilib-strict
violations which creep into the tree, isn't there a viable QA_something
we can use for this one ebuild instead of disabling a critical sanity check?

- -Zero_Chaos
>
> $ file /usr/lib/udisks2/udisksd
> /usr/lib/udisks2/udisksd: ELF 64-bit LSB executable, x86-64, version 1
> (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
> stripped
>
> $ file /usr/lib/udev/* |grep ELF
> /usr/lib/udev/accelerometer: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/ata_id: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/cdrom_id: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/collect: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/hid2hci: ELF 64-bit LSB shared object,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/ift-load: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/ipod-set-info: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/keymap: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/mtd_probe: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/mtp-probe: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/scsi_id: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/udev-configure-printer: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/udisks-dm-export: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/udisks-lvm-pv-export: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/udisks-part-id: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/udisks-probe-ata-smart: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/udisks-probe-sas-expander: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/v4l_id: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
>
> I propably won't be working on this much, so help would be appericiated
> for restoring working multilib-strict check.
>
> Thanks, Samuli
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQKUamAAoJEKXdFCfdEflKrAkP/0FykSpEUSmKDDPOWzMDIEx0
mdBIHu1o709ZKxITacfee6KIM2nxQCPim6qykczePevKWQ3GS5 MRe0PiLgfb9/Y1
3DcTtCBFn+YlvpI/Esg2Ei8zrXokO2/etwCXCyyd6PbHhTKAetbQ6uOvMQnl0GOd
U/UykQITHGLDm2fqZR1OTXKfR8QzjD5+AtPbkx8kDN3k/IxpMbCaShRnzz7ScDab
MFzrIfpz4Swxkmolo5awYvpb+6qWGDH8/9OND2kev57clkUOO5TkaZq3T26sPXFP
tMMLOYKjYc20BN4AE9hgjMX75egaqQuKJli2dh4L7VYLWg3VEq aJghfhL5p52vRM
n/zjkjX0QP/wtb0Qa3i3Y0tL2VIm0iburb0SIQhO992vaOhoTTaYSHcNr5bU/ZUW
nyrbr9BL1sHOz39cg+oeKB7e40VlaoeybjHCHCJ1v0tjKjrf2j TTFJQN7hkk5tx+
MVxYY8+1QOWCJJO4Ft2Oa8JBuaCBcBeFb4ZOZZdZO86vvRzOqx EmfPmxu0pZqsbT
9JIwQrg5hUXaknZKT/Ib1Ibm3lrCSj6zSW31VbAAVX/crLYgT+fSq7UxrVbj4lGM
k2wEzrbPoX7eC6xM4ZDdU1OHKvXV5HJExCgQ9lA1xsNlxo13E7 cg6xkKXApxUeDM
+K1Fbp7ZqnRekj1FbUpO
=MP0C
-----END PGP SIGNATURE-----
 
Old 08-13-2012, 06:29 PM
Alexandre Rostovtsev
 
Default FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Petten wrote:
> Beside the fact that these would probably have looked better in
> /usr/libexec

See Kay Sievers's comment at
https://bugs.freedesktop.org/show_bug.cgi?id=51617 :

"/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It
shares absolutely zero things with the arch-specific $libdir ,or lib64/.

/usr/lib/<pkgname>/ is the canonical "application private directory". It
has the multi-lib or arch-specific rules as /bin.

It just happens to be the same directory as $libdir for 32bit
installations in the classic non-multi-arch layout, which might go away
over time, but that is absolutely no reason to symlink it away.

Having /lib pointing to /lib64 is plain wrong, and should not explicitly
be supported by upstream build systems. If it happens to be that
libexecdir works for that, then it's fine, but it is surely not treated
as a bug if it isn't."

-Alexandre
 
Old 08-13-2012, 09:24 PM
Diego Elio Pettenò
 
Default FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

On 13/08/2012 11:29, Alexandre Rostovtsev wrote:
> "/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It
> shares absolutely zero things with the arch-specific $libdir ,or lib64/.

Yes I know that FHS allows it. I still think it would be cleaner to use
/usr/libexec.

It's the usual difference between trying to be right and being pragmatic
about it.

You (and Kay) want to be right ignoring the fact that $tons of software
expects /usr/lib to just be another $libdir.

I'd rather be pragmatic and choose /usr/libexec which _clearly_ isn't.

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
 
Old 08-13-2012, 09:56 PM
Mike Gilbert
 
Default FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

On Mon, Aug 13, 2012 at 2:29 PM, Alexandre Rostovtsev
<tetromino@gentoo.org> wrote:
> On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Petten wrote:
>> Beside the fact that these would probably have looked better in
>> /usr/libexec
>
> See Kay Sievers's comment at
> https://bugs.freedesktop.org/show_bug.cgi?id=51617 :
>
> "/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It
> shares absolutely zero things with the arch-specific $libdir ,or lib64/.
>
> /usr/lib/<pkgname>/ is the canonical "application private directory". It
> has the multi-lib or arch-specific rules as /bin.
>

So... where should GRUB2 be installing its modules? Currently they get
installed in /usr/$(get_libdir)/grub/$cpu-$platform, where cpu and
platform are determined by use flags.

Should we drop the get_libdir and put them in /usr/lib/grub instead?
Should I even worry about it?
 
Old 08-14-2012, 12:24 AM
Olivier Crte
 
Default FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

On Mon, 2012-08-13 at 17:56 -0400, Mike Gilbert wrote:
> On Mon, Aug 13, 2012 at 2:29 PM, Alexandre Rostovtsev
> <tetromino@gentoo.org> wrote:
> > On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Petten wrote:
> >> Beside the fact that these would probably have looked better in
> >> /usr/libexec
> >
> > See Kay Sievers's comment at
> > https://bugs.freedesktop.org/show_bug.cgi?id=51617 :
> >
> > "/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It
> > shares absolutely zero things with the arch-specific $libdir ,or lib64/.
> >
> > /usr/lib/<pkgname>/ is the canonical "application private directory". It
> > has the multi-lib or arch-specific rules as /bin.
> >
>
> So... where should GRUB2 be installing its modules? Currently they get
> installed in /usr/$(get_libdir)/grub/$cpu-$platform, where cpu and
> platform are determined by use flags.
>
> Should we drop the get_libdir and put them in /usr/lib/grub instead?
> Should I even worry about it?

There really have no reason to be in $(get_libdir) as they're not
compiled for the platform implied by $(get_libdir) !

--
Olivier Crte
tester@gentoo.org
Gentoo Developer
 
Old 08-14-2012, 09:57 AM
Samuli Suominen
 
Default FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

On 14.08.2012 00:24, Diego Elio Petten wrote:

On 13/08/2012 11:29, Alexandre Rostovtsev wrote:

"/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It
shares absolutely zero things with the arch-specific $libdir ,or lib64/.


Yes I know that FHS allows it. I still think it would be cleaner to use
/usr/libexec.


I highly dislike libexec and have been moving stuff over /usr/lib/$pkg/
on "daily basis"



You (and Kay) want to be right ignoring the fact that $tons of software
expects /usr/lib to just be another $libdir.


Count me in then I guess :/
 
Old 08-14-2012, 10:01 AM
Samuli Suominen
 
Default FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

On 14.08.2012 03:24, Olivier Crte wrote:

On Mon, 2012-08-13 at 17:56 -0400, Mike Gilbert wrote:

On Mon, Aug 13, 2012 at 2:29 PM, Alexandre Rostovtsev
<tetromino@gentoo.org> wrote:

On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Petten wrote:

Beside the fact that these would probably have looked better in
/usr/libexec


See Kay Sievers's comment at
https://bugs.freedesktop.org/show_bug.cgi?id=51617 :

"/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It
shares absolutely zero things with the arch-specific $libdir ,or lib64/.

/usr/lib/<pkgname>/ is the canonical "application private directory". It
has the multi-lib or arch-specific rules as /bin.



So... where should GRUB2 be installing its modules? Currently they get
installed in /usr/$(get_libdir)/grub/$cpu-$platform, where cpu and
platform are determined by use flags.

Should we drop the get_libdir and put them in /usr/lib/grub instead?
Should I even worry about it?


There really have no reason to be in $(get_libdir) as they're not
compiled for the platform implied by $(get_libdir) !



+1, that's correct.
 
Old 08-14-2012, 01:35 PM
Diego Elio Pettenò
 
Default FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

On 14/08/2012 02:57, Samuli Suominen wrote:
> I highly dislike libexec and have been moving stuff over /usr/lib/$pkg/
> on "daily basis"

So instead of discussing this you just decide you don't like the path
and go with your preference?

Honestly I would have preferred for this to go through council as _it
already went through it once_....

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
 

Thread Tools




All times are GMT. The time now is 11:22 AM.

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