Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]

On Sat, Nov 10, 2012 at 10:00:33AM +0100, Fabian Groffen wrote:
> On 09-11-2012 19:42:06 -0600, William Hubbs wrote:
> > > I thought so too, until I got dangling symlinks for older zlib for some
> > > reason (preserve-libs? ebuild?) which wasn't really a funny experience.
> > 
> > What symlinks did you have?
> 
> lib/libz.so.1 -> libz.so.1.2.5
> (I upgraded 1.2.5 to 1.2.7)

Looking at the code further in gen_usr_ldscript, it only uses symlinks
in one case, and that is in darwin, because their linker doesn't
understand nlinker scripts. It puts a symlink in /usr/lib* that points
to the library in /lib/* instead of a linker script.

> > If we do this with a variable, I suggest using it temporarily, but
> > ultimately dropping it and having everyone switch over after things are tested.
> 
> We know that FreeBSD will never (for how it looks now) follow, so we
> need to keep the code anyway.  Since it breaks e.g. Darwin, I'd like not
> to disappoint my users by saying: "sorry, you'll have to reinstall".

The *bsds and Darwin are not what I'm discussing; of course we have to
keep the code for them. I'm not disagreeing with you here either. The
change I'm talking about will not affect alternate platforms. :-)

The change I'm talking about, again after giving linux users a window to
migrate to initramfs or busybox[sep-usr], would be to remove the
'*linux*|' from line 623 of toolchain-funcs.eclass, or if we need
another variable for this, add something else to that branch of the 
the case statement for a while and remove the '*linux*|' and the new
code later.

Given that, I don't understand why you are thinking you will have to
tell your users that they will have to reinstall. Reinstalllation is not
part of this.

> Last but not least, I see no reason (given we have to keep the code
> anyway) to make sysadmins, that feel unsure about this on their running
> production systems, go into this route.  You don't know what custom code
> they have installed/running.  They'll be on their own (no
> udev/GNOME/whatever support), but most likely they won't care about that
> at all.

No, we don't know what custom code people are running, but custom
someone is running is not an excuse to block change. We just
have to make change happen in an orderly fashion and make sure people
are aware of the change so they can find ways on their end to adapt.
Isn't that reasonable?

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]