Re: [gentoo-user] Profile 17.1 fails at the analyse stage
On 20/6/19 9:40 pm, Rich Freeman wrote: > On Thu, Jun 20, 2019 at 9:21 AM Jack wrote: >> The --analyze phase bailed out before even starting. I filed an issue >> upstream (mgorny's github repository) and he made a change (I didn't >> look at the actual commit) so this situation should now be handled >> correctly. I think he did want to accept anything that ended up >> pointing to the right place, but was afraid of ending up with an >> unpredictable result, so now it will accept either the relative or >> absolute form. I don't know when he will release a new version. >> > IMO that was the right design choice. You just don't want to mess > around with these symlinks without care, so it is better to test that > everything is as expected. Otherwise you'll break some system that > somebody had tweaked 5 years ago and forgotten about. This way the > edge cases get reported, and can be taken into account before opening > things up more... > 2 out of 7 systems have this style symlink - one is quite old (many years), the other only one year or so. How system level links would happen in this way is strange. Both systems have been through (in some cases multiple) restores from backup which may have been the cause. BillK
Re: [gentoo-user] Profile 17.1 fails at the analyse stage
On Thu, Jun 20, 2019 at 9:21 AM Jack wrote: > > The --analyze phase bailed out before even starting. I filed an issue > upstream (mgorny's github repository) and he made a change (I didn't > look at the actual commit) so this situation should now be handled > correctly. I think he did want to accept anything that ended up > pointing to the right place, but was afraid of ending up with an > unpredictable result, so now it will accept either the relative or > absolute form. I don't know when he will release a new version. > IMO that was the right design choice. You just don't want to mess around with these symlinks without care, so it is better to test that everything is as expected. Otherwise you'll break some system that somebody had tweaked 5 years ago and forgotten about. This way the edge cases get reported, and can be taken into account before opening things up more... -- Rich
Re: [gentoo-user] Profile 17.1 fails at the analyse stage
On 6/20/19 3:47 AM, Peter Humphrey wrote: On Thursday, 20 June 2019 00:02:35 BST Bill Kenworthy wrote: On 20/6/19 2:26 am, Jack wrote: Bill - you might try "rm /usr/lib" WITHOUT the trailing slash, to remove the symlink. Then "ln -s lib64 /usr/lib" will recreate it in the form unsymlink-lib seems to require. Thanks, nicely picked! Hair split and now all works as intended. Just found another system with the same problem too. Why is it a problem? The instructions clearly stated that the symlink might not be revmoved, and that you should remove it yourself in that case. The --analyze phase bailed out before even starting. I filed an issue upstream (mgorny's github repository) and he made a change (I didn't look at the actual commit) so this situation should now be handled correctly. I think he did want to accept anything that ended up pointing to the right place, but was afraid of ending up with an unpredictable result, so now it will accept either the relative or absolute form. I don't know when he will release a new version.
Re: [gentoo-user] Profile 17.1 fails at the analyse stage
On 20/6/19 3:47 pm, Peter Humphrey wrote: > On Thursday, 20 June 2019 00:02:35 BST Bill Kenworthy wrote: >> On 20/6/19 2:26 am, Jack wrote: >>> Bill - you might try "rm /usr/lib" WITHOUT the trailing slash, to >>> remove the symlink. Then "ln -s lib64 /usr/lib" will recreate it in >>> the form unsymlink-lib seems to require. >> Thanks, nicely picked! >> >> Hair split and now all works as intended. Just found another system >> with the same problem too. > Why is it a problem? The instructions clearly stated that the symlink might > not be revmoved, and that you should remove it yourself in that case. > Thats towards the end - I couldn't get past step 4 ... BillK
Re: [gentoo-user] Profile 17.1 fails at the analyse stage
On Thursday, 20 June 2019 00:02:35 BST Bill Kenworthy wrote: > On 20/6/19 2:26 am, Jack wrote: > > Bill - you might try "rm /usr/lib" WITHOUT the trailing slash, to > > remove the symlink. Then "ln -s lib64 /usr/lib" will recreate it in > > the form unsymlink-lib seems to require. > > Thanks, nicely picked! > > Hair split and now all works as intended. Just found another system > with the same problem too. Why is it a problem? The instructions clearly stated that the symlink might not be revmoved, and that you should remove it yourself in that case. -- Regards, Peter.
Re: [gentoo-user] Profile 17.1 fails at the analyse stage
On 20/6/19 2:26 am, Jack wrote: > On 2019.06.19 14:10, Neil Bothwick wrote: >> On Wed, 19 Jun 2019 20:45:03 +0800, Bill Kenworthy wrote: >> >> > wifi ~ # unsymlink-lib --analyze >> > /usr/lib needs to be a symlink to lib64! >> > wifi ~ # ls -al /usr/lib >> > lrwxrwxrwx 1 root root 10 Jan 4 13:37 /usr/lib -> /usr/lib64 >> > wifi ~ # >> > >> > The symlink looks the same as another unconverted system - so whats >> the >> > problem? >> >> On this system, /usr/lib is a symlink to lib64, as the message states, >> not /usr/lib64 >> >> % ls -ld /usr/lib >> lrwxrwxrwx 1 root root 5 Jul 16 2015 /usr/lib -> lib64 >> >> >> -- >> Neil Bothwick > Ah, I think we've gotten to a bad splitting of hairs. /usr/lib -> > lib64 and /usr/lib -> /usr/lib64 have the same effect, but are not > quite the same. The first is a relative symlink, the second is > absolute, although both actually point to the same place. > > Bill - you might try "rm /usr/lib" WITHOUT the trailing slash, to > remove the symlink. Then "ln -s lib64 /usr/lib" will recreate it in > the form unsymlink-lib seems to require. > > Jack Thanks, nicely picked! Hair split and now all works as intended. Just found another system with the same problem too. BillK
Re: [gentoo-user] Profile 17.1 fails at the analyse stage
On 2019.06.19 16:14, Neil Bothwick wrote: On Wed, 19 Jun 2019 14:26:50 -0400, Jack wrote: > On 2019.06.19 14:10, Neil Bothwick wrote: > > On Wed, 19 Jun 2019 20:45:03 +0800, Bill Kenworthy wrote: > > > > > wifi ~ # unsymlink-lib --analyze > > > /usr/lib needs to be a symlink to lib64! > > > wifi ~ # ls -al /usr/lib > > > lrwxrwxrwx 1 root root 10 Jan 4 13:37 /usr/lib -> /usr/lib64 > > > wifi ~ # > > > > > > The symlink looks the same as another unconverted system - so > > > whats > > the > > > problem? > > > > On this system, /usr/lib is a symlink to lib64, as the message states, > > not /usr/lib64 > > > > % ls -ld /usr/lib > > lrwxrwxrwx 1 root root 5 Jul 16 2015 /usr/lib -> lib64 > Ah, I think we've gotten to a bad splitting of hairs. /usr/lib -> > lib64 and /usr/lib -> /usr/lib64 have the same effect, but are not > quite the same. The first is a relative symlink, the second is > absolute, although both actually point to the same place. That's what software does, it interprets things literally. It is looking for a symlink to lib64 and finding something else. The fact that the actual link is equivalent is also irrelevant. Agreed, but in this case, it is the end outcome which really matters, so I would consider that an inadequacy (not sure whether it quite counts as a bug) in the script. It won't help the OP much, but filing a bug against unsymlink-lib might get acted on. It is also possible to file an issue against it in its github repository.
Re: [gentoo-user] Profile 17.1 fails at the analyse stage
On Wed, 19 Jun 2019 14:26:50 -0400, Jack wrote: > On 2019.06.19 14:10, Neil Bothwick wrote: > > On Wed, 19 Jun 2019 20:45:03 +0800, Bill Kenworthy wrote: > > > > > wifi ~ # unsymlink-lib --analyze > > > /usr/lib needs to be a symlink to lib64! > > > wifi ~ # ls -al /usr/lib > > > lrwxrwxrwx 1 root root 10 Jan 4 13:37 /usr/lib -> /usr/lib64 > > > wifi ~ # > > > > > > The symlink looks the same as another unconverted system - so > > > whats > > the > > > problem? > > > > On this system, /usr/lib is a symlink to lib64, as the message states, > > not /usr/lib64 > > > > % ls -ld /usr/lib > > lrwxrwxrwx 1 root root 5 Jul 16 2015 /usr/lib -> lib64 > Ah, I think we've gotten to a bad splitting of hairs. /usr/lib -> > lib64 and /usr/lib -> /usr/lib64 have the same effect, but are not > quite the same. The first is a relative symlink, the second is > absolute, although both actually point to the same place. That's what software does, it interprets things literally. It is looking for a symlink to lib64 and finding something else. The fact that the actual link is equivalent is also irrelevant. -- Neil Bothwick The severity of the itch is inversely proportional to the reach. pgptMvQSPJOu7.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Profile 17.1 fails at the analyse stage
On 2019.06.19 14:10, Neil Bothwick wrote: On Wed, 19 Jun 2019 20:45:03 +0800, Bill Kenworthy wrote: > wifi ~ # unsymlink-lib --analyze > /usr/lib needs to be a symlink to lib64! > wifi ~ # ls -al /usr/lib > lrwxrwxrwx 1 root root 10 Jan 4 13:37 /usr/lib -> /usr/lib64 > wifi ~ # > > The symlink looks the same as another unconverted system - so whats the > problem? On this system, /usr/lib is a symlink to lib64, as the message states, not /usr/lib64 % ls -ld /usr/lib lrwxrwxrwx 1 root root 5 Jul 16 2015 /usr/lib -> lib64 -- Neil Bothwick Ah, I think we've gotten to a bad splitting of hairs. /usr/lib -> lib64 and /usr/lib -> /usr/lib64 have the same effect, but are not quite the same. The first is a relative symlink, the second is absolute, although both actually point to the same place. Bill - you might try "rm /usr/lib" WITHOUT the trailing slash, to remove the symlink. Then "ln -s lib64 /usr/lib" will recreate it in the form unsymlink-lib seems to require. Jack
Re: [gentoo-user] Profile 17.1 fails at the analyse stage
On Wed, 19 Jun 2019 20:45:03 +0800, Bill Kenworthy wrote: > wifi ~ # unsymlink-lib --analyze > /usr/lib needs to be a symlink to lib64! > wifi ~ # ls -al /usr/lib > lrwxrwxrwx 1 root root 10 Jan 4 13:37 /usr/lib -> /usr/lib64 > wifi ~ # > > The symlink looks the same as another unconverted system - so whats the > problem? On this system, /usr/lib is a symlink to lib64, as the message states, not /usr/lib64 % ls -ld /usr/lib lrwxrwxrwx 1 root root 5 Jul 16 2015 /usr/lib -> lib64 -- Neil Bothwick TEXAS VIRUS: Makes sure that it's bigger than any other file. pgpzqTJEt96uM.pgp Description: OpenPGP digital signature
