Re: [gentoo-dev] Allow variable refs in HOMEPAGE
> On Thu, 3 Aug 2017, Michael Orlitzky wrote: > On 08/03/2017 06:33 PM, Ulrich Mueller wrote: >> It did, even back in 2004: >> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?hideattic=0&revision=1.10&view=markup#l534 > You got me, but now we can see where that text came from and it > proves my original point that the last line was added as an > afterthought and isn't any sort of policy: > https://bugs.gentoo.org/show_bug.cgi?id=73272 Huh? We don't know if these changes result from a previous discussion, or codify best practice at the time. Given that the comment says "consolidate [...] into the Ebuild HOWTO" I would assume that they don't appear out of the blue there. Besides, something that sits in the handbook and devmanual uncontested since more than a decade certainly is a policy. > Which is good, because it's a silly rule, and hundreds of ebuilds in > the tree wisely ignore it. > Why single out HOMEPAGE? I might like to copy/paste the econf > arguments, so should we forbid the use of $(use_enable foo) and > force everyone to use "if" statements? Of course not; if you need > the value of HOMEPAGE (or anything else), there are more intelligent > ways to get it than opening up the ebuild, digging though the source > code, and manually performing the variable substitutions that the > programming language is there to do for us. > Use the metadata, use eix, use emerge --search, write an echo > statement into the ebuild, whatever. Don't handicap everyone so that > you can treat their source code as part of your user interface. All very well, but it requires the ebuild to a) be parseable by the package manager and b) already exist inside of an ebuild repository. Which is for example not the case for a user contributed ebuild attached to bugzilla. Ulrich pgpfp4wYjo1do.pgp Description: PGP signature
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On czw, 2017-08-03 at 23:24 -0400, Michael Orlitzky wrote: > On 08/03/2017 06:33 PM, Ulrich Mueller wrote: > > > > > > > On Thu, 3 Aug 2017, Michael Orlitzky wrote: > > > The developer handbook that I just said didn't mention variables in > > > HOMEPAGE at all. > > > > It did, even back in 2004: > > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?hideattic=0&revision=1.10&view=markup#l534 > > > > You got me, but now we can see where that text came from and it proves > my original point that the last line was added as an afterthought and > isn't any sort of policy: > > https://bugs.gentoo.org/show_bug.cgi?id=73272 > > Which is good, because it's a silly rule, and hundreds of ebuilds in the > tree wisely ignore it. There's a significant difference between being unaware of a policy and intentionally disrespecting it. Now that you've been made aware, we can start pursuing it. > Why single out HOMEPAGE? I might like to copy/paste the econf arguments, > so should we forbid the use of $(use_enable foo) and force everyone to > use "if" statements? Of course not; if you need the value of HOMEPAGE > (or anything else), there are more intelligent ways to get it than > opening up the ebuild, digging though the source code, and manually > performing the variable substitutions that the programming language is > there to do for us. > > Use the metadata, use eix, use emerge --search, write an echo statement > into the ebuild, whatever. Don't handicap everyone so that you can treat > their source code as part of your user interface. Why is it fine for you to handicap everyone else for your personal laziness? As it's been told more than once, you write ebuild *once*, people read it *multiple times*. When reviewing pull requests, submitted ebuilds etc. I *have to* verify this stuff. I don't have time to copy everything to a local tree just to get some random tool process it correctly and give me the value I need. Just to figure out there's some trivial issue that blocks any further progress, and I will have to do this again, and again, and again. Because someone thinks it's cool to save 5 bytes in variable references. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On 08/03/2017 06:33 PM, Ulrich Mueller wrote: >> On Thu, 3 Aug 2017, Michael Orlitzky wrote: > >> The developer handbook that I just said didn't mention variables in >> HOMEPAGE at all. > > It did, even back in 2004: > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?hideattic=0&revision=1.10&view=markup#l534 > You got me, but now we can see where that text came from and it proves my original point that the last line was added as an afterthought and isn't any sort of policy: https://bugs.gentoo.org/show_bug.cgi?id=73272 Which is good, because it's a silly rule, and hundreds of ebuilds in the tree wisely ignore it. Why single out HOMEPAGE? I might like to copy/paste the econf arguments, so should we forbid the use of $(use_enable foo) and force everyone to use "if" statements? Of course not; if you need the value of HOMEPAGE (or anything else), there are more intelligent ways to get it than opening up the ebuild, digging though the source code, and manually performing the variable substitutions that the programming language is there to do for us. Use the metadata, use eix, use emerge --search, write an echo statement into the ebuild, whatever. Don't handicap everyone so that you can treat their source code as part of your user interface.
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On Thu, Aug 03, 2017 at 05:54:17PM +0200, Michał Górny wrote:
> d. no random ${PN} all over the install phase.
I think some qualification of "random ${PN} all over the install phase"
needs to be made - how random is random, are there any allowed
instances?
AFAIK with the exception of some system-wide resources (eg. themes,
icons, fonts) packages installing to locations such as /usr/share and
/usr/share/doc should install to directories named after the package (as
in after ${PN} or ${PF}). This means, when writing src_install(), that
use of those variables would be necessary. Should we always use ${PF}
instead, or are some instances of ${PN} reasonable?
--
Sam Jorna (wraeth)
GnuPG Key: D6180C26
signature.asc
Description: Digital signature
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
> On Thu, 3 Aug 2017, Michael Orlitzky wrote: > On 08/03/2017 03:39 PM, Mike Gilbert wrote: >> The developer handbook was also a "policy" manual of sorts when it >> existed. > The developer handbook that I just said didn't mention variables in > HOMEPAGE at all. It did, even back in 2004: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?hideattic=0&revision=1.10&view=markup#l534 Ulrich pgpB9j95w23fL.pgp Description: PGP signature
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On Thu, Aug 3, 2017 at 11:54 AM, Michał Górny wrote:
> On czw, 2017-08-03 at 11:33 -0400, Mike Gilbert wrote:
>> I would like to remove the ban on variable references in the HOMEPAGE
>> variable in ebuilds.
>>
>> As I understand it, this ban was put in place so that people can
>> easily copy/paste from an ebuild to a web browser.
>>
>> If people want to copy/paste the URL, they can easily query the final
>> value using the portage API, or a tool written against it.
>
> I object! Portage API does not work conveniently for ebuilds scattered
> all over the place, or visible through gitweb.
>
> In fact, I would like to request an opposite motion: I would like to ban
> all constant-value variable references unless they give a *very* large
> measurable benefit.
>
> I'm really tired of people who try hard to replace everything with
> a variable when it doesn't give any benefit. It only means that:
>
> - when reviewing multiple ebuilds, I constantly need to look at PN to
> figure out whether someone didn't screw up the vars,
>
> - things are not suitable for straightforward copy-paste for testing,
>
> - everything falls apart when someone renames the package (either us or
> upstream). In particular, it becomes PITA to figure out which ${PN}
> represent the upstream name, and which ones strictly refer to the
> package name.
>
> In other words:
>
> a. P/PV/PF are acceptable because versions change frequently,
>
> b. PN might be acceptable when used for MY_P and so on,
>
> c. no variables in HOMEPAGE, EGIT_REPO_URI, constant part of SRC_URI
> (so I could at least open the directory containing the file),
>
> d. no random ${PN} all over the install phase.
After thinking about it, I suppose this makes sense. If we can get
some agreement to use ${PN} and other static values as little as
possible, I can support that.
What really doesn't make sense to me is to ban it just for HOMEPAGE,
but allow it everywhere else.
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On Thu, Aug 3, 2017 at 3:56 PM, Michael Orlitzky wrote: > On 08/03/2017 03:39 PM, Mike Gilbert wrote: >>> >>> (The old handbook never mentioned variables, from what I can see.) >>> >> >> The developer handbook was also a "policy" manual of sorts when it existed. > > The developer handbook that I just said didn't mention variables in > HOMEPAGE at all. > I really doubt that, but I'm not going to spend time trying to track it down. Anyway, it's been in the devmanual for 10 years at this point. I don't feel comfortable just removing it without some kind of developer consensus or support from QA/council.
[gentoo-dev] Last rites: sys-kernel/openvz-sources, sys-apps/yum, sys-boot/plymouth, media-libs/silgraphite and revdeps
# Michał Górny (04 Aug 2017) # Obsolete. Replaced by media-gfx/graphite2. No longer used # by anything. Removal in 30 days. Bug #594314. media-libs/silgraphite # Michał Górny (04 Aug 2017) # Dependency of dev-texlive/texlive-basic-2012 no longer needed for # the current versions. Removal in 14 days. dev-texlive/texlive-documentation # Michał Górny (04 Aug 2017) # sys-boot/plymouth is unmaintained since Apr 2016. The current version # has multiple bugs, including not supporting OpenRC. It really needs # an active maintainer. Removal in 30 days. Bug #621470. # # The remaining packages are sys-boot/plymouth reverse dependencies. # They have no use without it, so they are being removed as well. kde-plasma/breeze-plymouth kde-plasma/plymouth-kcm sys-boot/plymouth sys-boot/plymouth-openrc-plugin # Michał Górny (04 Aug 2017) # sys-apps/yum is severely outdated (last bump 2013), unmaintained # since 2010. It has vulnerabilities. Removal in 30 days. Bug #499328. # # app-arch/createrepo is the last unmasked dependency. Since it is not # useful at all without yum, it is being removed as well. Bug #620992. app-arch/createrepo sys-apps/yum # Michał Górny (04 Aug 2017) # Unmaintained since mid-2016, requires an active maintainer. Has # multiple build failure bugs. Removal in 30 days. Bug #580516. sys-kernel/openvz-sources -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On 08/03/2017 03:39 PM, Mike Gilbert wrote: >> >> (The old handbook never mentioned variables, from what I can see.) >> > > The developer handbook was also a "policy" manual of sorts when it existed. The developer handbook that I just said didn't mention variables in HOMEPAGE at all.
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On Thu, Aug 3, 2017 at 3:12 PM, Michael Orlitzky wrote: > On 08/03/2017 02:57 PM, Mike Gilbert wrote: >> >> It's in the devmanual, which imposes gentoo-specific policy on top of PMS. >> > > It would be nice if that were true, but there's a lot of junk and/or > personal preference documented in the devmanual, and a lot of > actual-policy that's still missing because it can't get past review. > This looks like it was tacked on for fun as part of the devrel handbook > merger: > > https://github.com/gentoo/devmanual.gentoo.org/commit/c97aec7f7e236bc917067763916530bfa05d6e31 > > (The old handbook never mentioned variables, from what I can see.) > The developer handbook was also a "policy" manual of sorts when it existed. I don't know where you got the idea that developers are free to ignore the devmanual when it suits them. You might get away with it if QA doesn't notice I guess.
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
> On Thu, 3 Aug 2017, Michael Orlitzky wrote: > [...] Portage Manager Specification [...] D'oh! pgp6Uct6pop5G.pgp Description: PGP signature
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
> On Thu, 3 Aug 2017, Mike Gilbert wrote: > I would like to remove the ban on variable references in the > HOMEPAGE variable in ebuilds. I think this is not a good idea. For example, it would break browse-url-at-point (C-u u .) from within Emacs. > [...] > Allowing variables in HOMEPAGE would allow for easier copying of > similar/identical ebuilds. For example, see the trivial ebuilds in > my overlay below. Ebuilds are read more often than they are written. IMHO there is no benefit in optimising the latter at the expense of the former. Ulrich pgpX7gNIMQc2B.pgp Description: PGP signature
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On 08/03/2017 02:57 PM, Mike Gilbert wrote: > > It's in the devmanual, which imposes gentoo-specific policy on top of PMS. > It would be nice if that were true, but there's a lot of junk and/or personal preference documented in the devmanual, and a lot of actual-policy that's still missing because it can't get past review. This looks like it was tacked on for fun as part of the devrel handbook merger: https://github.com/gentoo/devmanual.gentoo.org/commit/c97aec7f7e236bc917067763916530bfa05d6e31 (The old handbook never mentioned variables, from what I can see.)
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On Thu, Aug 3, 2017 at 2:21 PM, Michael Orlitzky wrote: > On 08/03/2017 11:33 AM, Mike Gilbert wrote: >> I would like to remove the ban on variable references in the HOMEPAGE >> variable in ebuilds. >> > > What ban are you referring to? The Portage Manager Specification doesn't > say anything of the sort. It's in the devmanual, which imposes gentoo-specific policy on top of PMS.
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On czw, 2017-08-03 at 14:21 -0400, Michael Orlitzky wrote: > On 08/03/2017 11:33 AM, Mike Gilbert wrote: > > I would like to remove the ban on variable references in the HOMEPAGE > > variable in ebuilds. > > > > What ban are you referring to? The Portage Manager Specification doesn't > say anything of the sort. > > Seriously though, whatever sort of tricks your opponents think they're > doing with HOMEPAGE don't work. The HOMEPAGE can contain conditionals > (i.e. dependency syntax), so grepping and copy/pasting are unreliable, > and we should all continue doing whatever the heck we want. This argument makes no sense. The dependency syntax requires a lot of spaces which means clicking, copy-pasting and all other fancy stuff just works™. It's always nice when someone who doesn't do X tells those actually doing X that their method doesn't work without any research to support it. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On 08/03/2017 11:33 AM, Mike Gilbert wrote: > I would like to remove the ban on variable references in the HOMEPAGE > variable in ebuilds. > What ban are you referring to? The Portage Manager Specification doesn't say anything of the sort. Seriously though, whatever sort of tricks your opponents think they're doing with HOMEPAGE don't work. The HOMEPAGE can contain conditionals (i.e. dependency syntax), so grepping and copy/pasting are unreliable, and we should all continue doing whatever the heck we want.
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
Hi Mike, > I would like to remove the ban on variable references in the HOMEPAGE > variable in ebuilds. > > As I understand it, this ban was put in place so that people can > easily copy/paste from an ebuild to a web browser. It made it also possible to grep through the packages and find thousand dead HOMEPAGES like [1] and many more. If the HOMEPAGE is constructed by the power of bash variables it is hard to track and to use. We have already some HOMEPAGES which are constructed by eclass magic [2]. These do not link to a useful website usually. A string is also less error prone. We have already many broken HOMEPAGES. This number would only increase if we add variables. On the other hand it does not safe very much time for the maintainer. Ebuilds are written once, but read many times. Hence I suggest KISS (keep it simple stupid) and stick to the real URL without variables. [1] https://wiki.gentoo.org/wiki/Upstream_repository_shutdowns [2] https://bugs.gentoo.org/show_bug.cgi?id=624498 -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On czw, 2017-08-03 at 11:33 -0400, Mike Gilbert wrote:
> I would like to remove the ban on variable references in the HOMEPAGE
> variable in ebuilds.
>
> As I understand it, this ban was put in place so that people can
> easily copy/paste from an ebuild to a web browser.
>
> If people want to copy/paste the URL, they can easily query the final
> value using the portage API, or a tool written against it.
I object! Portage API does not work conveniently for ebuilds scattered
all over the place, or visible through gitweb.
In fact, I would like to request an opposite motion: I would like to ban
all constant-value variable references unless they give a *very* large
measurable benefit.
I'm really tired of people who try hard to replace everything with
a variable when it doesn't give any benefit. It only means that:
- when reviewing multiple ebuilds, I constantly need to look at PN to
figure out whether someone didn't screw up the vars,
- things are not suitable for straightforward copy-paste for testing,
- everything falls apart when someone renames the package (either us or
upstream). In particular, it becomes PITA to figure out which ${PN}
represent the upstream name, and which ones strictly refer to the
package name.
In other words:
a. P/PV/PF are acceptable because versions change frequently,
b. PN might be acceptable when used for MY_P and so on,
c. no variables in HOMEPAGE, EGIT_REPO_URI, constant part of SRC_URI
(so I could at least open the directory containing the file),
d. no random ${PN} all over the install phase.
> Allowing variables in HOMEPAGE would allow for easier copying of
> similar/identical ebuilds. For example, see the trivial ebuilds in my
> overlay below.
>
> https://bitbucket.org/floppym/floppym-overlay/src/8b55fab291ec1f9be93ade9c91e7d62d7b8a259d/dev-go/cloudflare-go/cloudflare-go-0.7.4.ebuild
>
> https://bitbucket.org/floppym/floppym-overlay/src/8b55fab291ec1f9be93ade9c91e7d62d7b8a259d/dev-go/pkg-errors/pkg-errors-0.8.0.ebuild
>
> https://bitbucket.org/floppym/floppym-overlay/src/8b55fab291ec1f9be93ade9c91e7d62d7b8a259d/dev-go/urfave-cli/urfave-cli-1.19.1.ebuild
Laziness shouldn't be an excuse to make things worse. You can write
yourself a tool that puts correct values there.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Allow variable refs in HOMEPAGE
I would like to remove the ban on variable references in the HOMEPAGE variable in ebuilds. As I understand it, this ban was put in place so that people can easily copy/paste from an ebuild to a web browser. If people want to copy/paste the URL, they can easily query the final value using the portage API, or a tool written against it. % equery m www-client/chromium * www-client/chromium [gentoo] Maintainer: chrom...@gentoo.org (Chromium in Gentoo Project) Upstream:None specified Homepage:http://chromium.org/ Location:/home/floppym/repos/gentoo/www-client/chromium Keywords:59.0.3071.104:0: x86 Keywords:60.0.3112.40:0: Keywords:60.0.3112.78:0: amd64 Keywords:61.0.3159.5:0: Keywords:61.0.3163.13:0: ~amd64 ~arm ~arm64 ~x86 License: BSD Allowing variables in HOMEPAGE would allow for easier copying of similar/identical ebuilds. For example, see the trivial ebuilds in my overlay below. https://bitbucket.org/floppym/floppym-overlay/src/8b55fab291ec1f9be93ade9c91e7d62d7b8a259d/dev-go/cloudflare-go/cloudflare-go-0.7.4.ebuild https://bitbucket.org/floppym/floppym-overlay/src/8b55fab291ec1f9be93ade9c91e7d62d7b8a259d/dev-go/pkg-errors/pkg-errors-0.8.0.ebuild https://bitbucket.org/floppym/floppym-overlay/src/8b55fab291ec1f9be93ade9c91e7d62d7b8a259d/dev-go/urfave-cli/urfave-cli-1.19.1.ebuild
[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review
Michał Górny wrote: > > I have been running such a layout for over a year. [...] Thanks for clarifying that this already was discussed. Obviously, I was not aware about this discussion, and perhaps I was not the only one. > instead of waking up last-minute to redesign [...] Pointing me to the discussion would have been sufficient: If this was already discussed, it makes no sense to open that bottle again. As mentioned in my first posting: In this case I am sorry for the noise.
Re: [gentoo-dev] can't gpg sign with repoman, but can with git
On 20/07/2017 11:38, Kristian Fiskerstrand wrote: > On 07/19/2017 09:24 PM, Paweł Hajdan, Jr. wrote: >> * 4 files being committed... >> error: gpg failed to sign the data >> fatal: failed to write commit object >> !!! Exiting on git (shell) error code: 128 > > you can increase gpg-agent logging verbosity in gpg-agent.conf: > log-file /home/user/my.log > debug-level guru > ... don't share the file outright, as it can contain sensitive info at > that debug level.. but it should give you a hint as to what is going on > if the request hits gpg-agent (and if not that is a point of info in itself) Thanks for the suggestion. I did above, but no log file was even created. I can still successfully commit with plain git. > fwiw, debugging this in #gentoo-crypto might be easier :) Okay, I'll try that. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review
On czw, 2017-08-03 at 07:50 +, Martin Vaeth wrote:
> Mike Gilbert wrote:
> > Debian puts 64-bit libs in /lib/(host)
>
> Yes, this is somewhat weird:
> They have /lib/i386-linux-gnu/ and /lib/x86_64-linux-gnu/
> but anyway they use /lib32 instead of e.g. /lib/i686-linux-gnu/
> Their reasons for this are mysterious to me.
>
> > Migrating Gentoo to a "multiarch" config is a larger project.
>
> Migrating to the completely split setting /lib{,32,64,x32}
> would be _less_ intrusive than to simultaneously omitting /lib32:
> With a slight modification of Michał's tool (in the instructions
> and keeping lib32 untouched) not even a re-emerge of anything
> would be necessary (as is the case now).
I have been running such a layout for over a year. I've stopped when
base-system proactively blocked it in baselayout, and multiple people
in Gentoo rejected providing support for it.
> This is one of the reasons why a completely split layout appears
> safer to me than to combine it with yet another new merge we
> have no experience with.
Except that it breaks every 32-bit x86 pre-built executable.
Anyway, this is off-topic and a waste of everyone's time. Please review
the tool instead of waking up last-minute to redesign everything that's
been designed for 10+ years.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review
Mike Gilbert wrote:
> Debian puts 64-bit libs in /lib/(host)
Yes, this is somewhat weird:
They have /lib/i386-linux-gnu/ and /lib/x86_64-linux-gnu/
but anyway they use /lib32 instead of e.g. /lib/i686-linux-gnu/
Their reasons for this are mysterious to me.
> Migrating Gentoo to a "multiarch" config is a larger project.
Migrating to the completely split setting /lib{,32,64,x32}
would be _less_ intrusive than to simultaneously omitting /lib32:
With a slight modification of Michał's tool (in the instructions
and keeping lib32 untouched) not even a re-emerge of anything
would be necessary (as is the case now).
This is one of the reasons why a completely split layout appears
safer to me than to combine it with yet another new merge we
have no experience with.
[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review
Michał Górny wrote: > > 'No mainstream' as you claim it doesn't mean it's fine to invent yet > another completely incompatible solution. As I understand, the compatibility with Debian might be increased (keeping /lib32), at the cost of slightly decreasing the compatibility with Red Hat (concerning 32bit emulation). So depending on the use case, it might as well be more compatible. >> in _all_ /lib* directories > > This is not true. You are right, I had made a stupid mistake. (I forgot that I still have the symlink lib->lib64 so that of course I should not have wondered why all ld-* existed in both libs...) > the linker uses /lib path independently of how multilib is done > on the system. I am not sure whether I understand what you mean. Do you mean that practically sys-libs/binutils or sys-libs/glibc have hardcoded /lib -> 32bit /lib64 -> 64bit (concerning ld-*) unless one patches it out? In this case you are right that there is an upstream to follow. In this case I wonder why Debian decided to patch out this upstream decision to support /lib32. > The 32-bit proprietary binaries use exactly /lib which is the main > reason for the switch. I thought the main reason for the switch is to avoid the merging of /lib and /lib64 which in bug 506276 led to problems for debugging. For this reason I am afraid that now merging /lib and /lib32 might again lead to a similar type of problems. I am aware that exactly the cited problem is now mitigated, because this time the merging does not happen over a symlink. But anyway, it seems unnatural when "curing" from a merge to decide to merge something else.
