| 1 |
On Sat, Nov 10, 2012 at 10:00:33AM +0100, Fabian Groffen wrote: |
| 2 |
> On 09-11-2012 19:42:06 -0600, William Hubbs wrote: |
| 3 |
> > > I thought so too, until I got dangling symlinks for older zlib for some |
| 4 |
> > > reason (preserve-libs? ebuild?) which wasn't really a funny experience. |
| 5 |
> > |
| 6 |
> > What symlinks did you have? |
| 7 |
> |
| 8 |
> lib/libz.so.1 -> libz.so.1.2.5 |
| 9 |
> (I upgraded 1.2.5 to 1.2.7) |
| 10 |
|
| 11 |
Looking at the code further in gen_usr_ldscript, it only uses symlinks |
| 12 |
in one case, and that is in darwin, because their linker doesn't |
| 13 |
understand nlinker scripts. It puts a symlink in /usr/lib* that points |
| 14 |
to the library in /lib/* instead of a linker script. |
| 15 |
|
| 16 |
> > If we do this with a variable, I suggest using it temporarily, but |
| 17 |
> > ultimately dropping it and having everyone switch over after things are tested. |
| 18 |
> |
| 19 |
> We know that FreeBSD will never (for how it looks now) follow, so we |
| 20 |
> need to keep the code anyway. Since it breaks e.g. Darwin, I'd like not |
| 21 |
> to disappoint my users by saying: "sorry, you'll have to reinstall". |
| 22 |
|
| 23 |
The *bsds and Darwin are not what I'm discussing; of course we have to |
| 24 |
keep the code for them. I'm not disagreeing with you here either. The |
| 25 |
change I'm talking about will not affect alternate platforms. :-) |
| 26 |
|
| 27 |
The change I'm talking about, again after giving linux users a window to |
| 28 |
migrate to initramfs or busybox[sep-usr], would be to remove the |
| 29 |
'*linux*|' from line 623 of toolchain-funcs.eclass, or if we need |
| 30 |
another variable for this, add something else to that branch of the |
| 31 |
the case statement for a while and remove the '*linux*|' and the new |
| 32 |
code later. |
| 33 |
|
| 34 |
Given that, I don't understand why you are thinking you will have to |
| 35 |
tell your users that they will have to reinstall. Reinstalllation is not |
| 36 |
part of this. |
| 37 |
|
| 38 |
> Last but not least, I see no reason (given we have to keep the code |
| 39 |
> anyway) to make sysadmins, that feel unsure about this on their running |
| 40 |
> production systems, go into this route. You don't know what custom code |
| 41 |
> they have installed/running. They'll be on their own (no |
| 42 |
> udev/GNOME/whatever support), but most likely they won't care about that |
| 43 |
> at all. |
| 44 |
|
| 45 |
No, we don't know what custom code people are running, but custom |
| 46 |
someone is running is not an excuse to block change. We just |
| 47 |
have to make change happen in an orderly fashion and make sure people |
| 48 |
are aware of the change so they can find ways on their end to adapt. |
| 49 |
Isn't that reasonable? |
| 50 |
|
| 51 |
William |
Archives