Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

 

 

Gentoo dev RSS feed   Index | Next | Previous | View Threaded


ssuominen at gentoo

Aug 13, 2012, 9:55 AM

Post #1 of 19 (753 views)
Permalink
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


flameeyes at flameeyes

Aug 13, 2012, 11:14 AM

Post #2 of 19 (720 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

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 [at] flameeyes — http://blog.flameeyes.eu/


zerochaos at gentoo

Aug 13, 2012, 11:25 AM

Post #3 of 19 (728 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

-----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
mdBIHu1o709ZKxITacfee6KIM2nxQCPim6qykczePevKWQ3GS5MRe0PiLgfb9/Y1
3DcTtCBFn+YlvpI/Esg2Ei8zrXokO2/etwCXCyyd6PbHhTKAetbQ6uOvMQnl0GOd
U/UykQITHGLDm2fqZR1OTXKfR8QzjD5+AtPbkx8kDN3k/IxpMbCaShRnzz7ScDab
MFzrIfpz4Swxkmolo5awYvpb+6qWGDH8/9OND2kev57clkUOO5TkaZq3T26sPXFP
tMMLOYKjYc20BN4AE9hgjMX75egaqQuKJli2dh4L7VYLWg3VEqaJghfhL5p52vRM
n/zjkjX0QP/wtb0Qa3i3Y0tL2VIm0iburb0SIQhO992vaOhoTTaYSHcNr5bU/ZUW
nyrbr9BL1sHOz39cg+oeKB7e40VlaoeybjHCHCJ1v0tjKjrf2jTTFJQN7hkk5tx+
MVxYY8+1QOWCJJO4Ft2Oa8JBuaCBcBeFb4ZOZZdZO86vvRzOqxEmfPmxu0pZqsbT
9JIwQrg5hUXaknZKT/Ib1Ibm3lrCSj6zSW31VbAAVX/crLYgT+fSq7UxrVbj4lGM
k2wEzrbPoX7eC6xM4ZDdU1OHKvXV5HJExCgQ9lA1xsNlxo13E7cg6xkKXApxUeDM
+K1Fbp7ZqnRekj1FbUpO
=MP0C
-----END PGP SIGNATURE-----


tetromino at gentoo

Aug 13, 2012, 11:29 AM

Post #4 of 19 (724 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

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


flameeyes at flameeyes

Aug 13, 2012, 2:24 PM

Post #5 of 19 (718 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

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 [at] flameeyes — http://blog.flameeyes.eu/


floppym at gentoo

Aug 13, 2012, 2:56 PM

Post #6 of 19 (720 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

On Mon, Aug 13, 2012 at 2:29 PM, Alexandre Rostovtsev
<tetromino [at] gentoo> 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?


tester at gentoo

Aug 13, 2012, 5:24 PM

Post #7 of 19 (717 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

On Mon, 2012-08-13 at 17:56 -0400, Mike Gilbert wrote:
> On Mon, Aug 13, 2012 at 2:29 PM, Alexandre Rostovtsev
> <tetromino [at] gentoo> 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 Crête
tester [at] gentoo
Gentoo Developer
Attachments: signature.asc (0.19 KB)


ssuominen at gentoo

Aug 14, 2012, 2:57 AM

Post #8 of 19 (714 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

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 :/


ssuominen at gentoo

Aug 14, 2012, 3:01 AM

Post #9 of 19 (709 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

On 14.08.2012 03:24, Olivier Crête 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 [at] gentoo> 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.


flameeyes at flameeyes

Aug 14, 2012, 6:35 AM

Post #10 of 19 (713 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

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 [at] flameeyes — http://blog.flameeyes.eu/


mgorny at gentoo

Aug 14, 2012, 7:05 AM

Post #11 of 19 (710 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

On Tue, 14 Aug 2012 12:57:13 +0300
Samuli Suominen <ssuominen [at] gentoo> wrote:

> 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"

I believe we should be keeping «aligned» paths somewhere rather than
randomly moving stuff by hand. If you're saying that /usr/lib/${PN} ==
libexec, maybe we should put that into PMS as --libexecdir=?

--
Best regards,
Michał Górny
Attachments: signature.asc (0.31 KB)


ssuominen at gentoo

Aug 14, 2012, 9:57 AM

Post #12 of 19 (709 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

On 14.08.2012 16:35, Diego Elio Pettenò wrote:
> 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_....
>

Sorry I was vague in that statement, I meant moving to both /usr/lib/
when suitable (and usually the default from upstream lately) and
/usr/lib64/xfce* (Location of .so Xfce plugins)
Xfce had compability code for finding plugins from /usr/libexec only for
4.10 series, and is marked as -DXFCE_DEPRECATED code, 4.12 will solely
use /usr/lib64/xfce4/
I've done nothing against the status quo, only following sane reasoning
and defaults from upstreams who have made a strong case for it being so,
or when they have actually made it impossible without carrying custom
patches forever

So all good, I hope this cleared misunderstandings

- Samuli


ssuominen at gentoo

Aug 14, 2012, 10:03 AM

Post #13 of 19 (709 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

On 13.08.2012 19:55, Samuli Suominen wrote:
[ ... ]

I should mention that we have discussed this already,

https://bugs.gentoo.org/show_bug.cgi?id=364375

Which was a result of long gentoo-dev ML thread, unfortunately my search
foo failed and I couldn't find straight link to it

Why should we threat /usr than / any different in this regard, there was
large consensus /lib/udev should be used instead of /lib64/udev and
udev.pc's udevdir= is the path for "udev helpers", ELFs(!), and rules
among other things

It's completely fair to say that multilib-strict feature has been broken
ever since, years.

- Samuli


ssuominen at gentoo

Aug 14, 2012, 10:05 AM

Post #14 of 19 (709 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

On 14.08.2012 17:05, Michał Górny wrote:
> On Tue, 14 Aug 2012 12:57:13 +0300
> Samuli Suominen <ssuominen [at] gentoo> wrote:
>
>> 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"
>
> I believe we should be keeping «aligned» paths somewhere rather than
> randomly moving stuff by hand. If you're saying that /usr/lib/${PN} ==
> libexec, maybe we should put that into PMS as --libexecdir=?
>

I would agree to this.


ssuominen at gentoo

Aug 14, 2012, 10:05 AM

Post #15 of 19 (710 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

On 14.08.2012 17:05, Michał Górny wrote:
> On Tue, 14 Aug 2012 12:57:13 +0300
> Samuli Suominen <ssuominen [at] gentoo> wrote:
>
>> 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"
>
> I believe we should be keeping «aligned» paths somewhere rather than
> randomly moving stuff by hand. If you're saying that /usr/lib/${PN} ==
> libexec, maybe we should put that into PMS as --libexecdir=?
>

With a EAPI bump, of course, to prevent breakage.


ssuominen at gentoo

Aug 14, 2012, 10:07 AM

Post #16 of 19 (710 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

On 14.08.2012 19:57, Samuli Suominen wrote:
> On 14.08.2012 16:35, Diego Elio Pettenò wrote:
>> 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_....
>>
>
> Sorry I was vague in that statement, I meant moving to both /usr/lib/
> when suitable (and usually the default from upstream lately) and
> /usr/lib64/xfce* (Location of .so Xfce plugins)

and possible couple of others than /usr/lib64/xfce*... meh, should
really proof read my own msgs


flameeyes at flameeyes

Aug 14, 2012, 10:13 AM

Post #17 of 19 (710 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

On 14/08/2012 09:57, Samuli Suominen wrote:
>
> Sorry I was vague in that statement, I meant moving to both /usr/lib/
> when suitable (and usually the default from upstream lately) and
> /usr/lib64/xfce* (Location of .so Xfce plugins)
> Xfce had compability code for finding plugins from /usr/libexec only for
> 4.10 series, and is marked as -DXFCE_DEPRECATED code, 4.12 will solely
> use /usr/lib64/xfce4/
> I've done nothing against the status quo, only following sane reasoning
> and defaults from upstreams who have made a strong case for it being so,
> or when they have actually made it impossible without carrying custom
> patches forever

For plugins (if they are plugins) we really need to use the $libdir as
they are ABI-dependent, so I'm perfectly happy with moving them out of
libexec (shouldn't have been there in the first place).

I'd still would like a revisit by council for what concerns /usr/libexec
though. I'm afraid that last time I let it slide after Kugelfang
promised he would write a draft that never came, as we had issue with cups.

In general, I'm in favour of using lib (and not $libdir) if they are
_executables_, which means they are not loaded in the same address space
of any other program. I'm just concerned of having another hundred
directories in /usr/lib as that could slow down ld.so...

--
Diego Elio Pettenò — Flameeyes
flameeyes [at] flameeyes — http://blog.flameeyes.eu/


aballier at gentoo

Aug 14, 2012, 10:37 AM

Post #18 of 19 (715 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

On Tue, 14 Aug 2012 20:03:50 +0300
Samuli Suominen <ssuominen [at] gentoo> wrote:

> On 13.08.2012 19:55, Samuli Suominen wrote:
> [ ... ]
>
> I should mention that we have discussed this already,
>
> https://bugs.gentoo.org/show_bug.cgi?id=364375
>
> Which was a result of long gentoo-dev ML thread, unfortunately my
> search foo failed and I couldn't find straight link to it
>
> Why should we threat /usr than / any different in this regard, there
> was large consensus /lib/udev should be used instead of /lib64/udev
> and udev.pc's udevdir= is the path for "udev helpers", ELFs(!), and
> rules among other things
>
> It's completely fair to say that multilib-strict feature has been
> broken ever since, years.

well, i dont agree its fair :P
it breaks on _pie_ executables, which are not that common if you dont
run hardened.

what is broken, and has been broken since years is multilib-strict +
pie toolchain; a flaw in the multilib-strict detection system that gets
confused by 'file' output on pie executables :)

A.


vapier at gentoo

Aug 17, 2012, 8:43 PM

Post #19 of 19 (679 views)
Permalink
Re: FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423) [In reply to]

On Tuesday 14 August 2012 13:37:25 Alexis Ballier wrote:
> it breaks on _pie_ executables, which are not that common if you dont
> run hardened.

every Gentoo system has PIEs on it. not many, but some.

file /*bin/* /usr/*bin/* | grep shared.object

(i wonder why cups is building itself as PIE actually ...)
-mike
Attachments: signature.asc (0.82 KB)

Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.