FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 07-11-2012, 02:25 AM
Allan McRae
 
Default News item: /lib removal - Was: heads up: /lib removal

On 11/07/12 11:32, Dan McGee wrote:
> On Tue, Jul 10, 2012 at 5:26 PM, Allan McRae <allan@archlinux.org> wrote:
>> A patched version of pacman is now in [testing] that will detect all the
>> issues reported so far that resulted in failed updates. Users of the
>> [testing] repo who last updated in the three days between the kmod
>> update and the glibc update may still run into issues, but "pacman -Sy
>> pacman && pacman -Su" will prevent that.
>>
>> Here is a (very draft) news item. I think it provides complete update
>> instructions for people using the "stable" repos.
>>
>>
>>
>> Removal of /lib directory
>>
>> All files in the /lib directory have been moved to /usr/lib and now /lib
>> is a symlink to usr/lib. During this update, pacman will identify a
>> conflict in the /lib directory. In the simplest case, this is worked
>> around by doing
>>
>> pacman -Syu --ignore glibc
>> pacman -Su
>>
>> When additional package depend on having a newer version of glibc than
>> is currently on your system and these also have files in /lib (e.g.
>> older versions of gcc), then and extra step will be necessary. For example:
>>
>> pacman -Syu --ignore glibc gcc
>> pacman -Sd gcc
>> pacman -Su
>>
>> Only do the -Sd step if really necessary. Pacman will warn you about a
>> conflict in /lib on the -Su step if it is.
>>
>> If the "pacman -Su" step reports a conflict in /lib, you will need to
>> look at all the files in /lib and determine which ones are not owned by
>> glibc. This is achieved by "pacman -Qo /lib/*". You will need to move
>
> find /lib -print0 | xargs -o pacman -Qo
> is much more effective at helping track down pesky files in
> subdirectories (ala catalyst-hook).

I figure that:
error: cannot determine ownership of directory '/lib/foo' is a good
hint, because these directories need removed too.

>> any files not belong to glibc to /usr/lib (either through fixing their
>> package or manually moving unowned files). There should be no
>> subdirectories in /lib either.
>>
>> Finally, NEVER use pacman --force (-f) for the glibc update. That will
>> result in a broken system.
>>
>>
>
> This package tripped me up for a while; what's the expected easy
> update path for those of us with it installed? Adding another three
> steps like `pacman -Rdd lib32-glibc`, then above commands, then
> reinstall seems very crazy to me, but that was the only way I found.
>
> lib32-glibc /lib/
> lib32-glibc /lib/ld-linux.so.2

lib32-glibc does not have a versioned dependency on glibc anymore so the
"pacman -Syu --ignore glibc" should still update it? Do you have
[multilib-testing] enabled?

Allan
 
Old 07-12-2012, 12:55 AM
Allan McRae
 
Default News item: /lib removal - Was: heads up: /lib removal

On 11/07/12 12:25, Allan McRae wrote:
> On 11/07/12 11:32, Dan McGee wrote:
>> On Tue, Jul 10, 2012 at 5:26 PM, Allan McRae <allan@archlinux.org> wrote:
>>> A patched version of pacman is now in [testing] that will detect all the
>>> issues reported so far that resulted in failed updates. Users of the
>>> [testing] repo who last updated in the three days between the kmod
>>> update and the glibc update may still run into issues, but "pacman -Sy
>>> pacman && pacman -Su" will prevent that.
>>>
>>> Here is a (very draft) news item. I think it provides complete update
>>> instructions for people using the "stable" repos.
>>>
>>>
>>>
>>> Removal of /lib directory
>>>
>>> All files in the /lib directory have been moved to /usr/lib and now /lib
>>> is a symlink to usr/lib. During this update, pacman will identify a
>>> conflict in the /lib directory. In the simplest case, this is worked
>>> around by doing
>>>
>>> pacman -Syu --ignore glibc
>>> pacman -Su
>>>
>>> When additional package depend on having a newer version of glibc than
>>> is currently on your system and these also have files in /lib (e.g.
>>> older versions of gcc), then and extra step will be necessary. For example:
>>>
>>> pacman -Syu --ignore glibc gcc
>>> pacman -Sd gcc
>>> pacman -Su
>>>
>>> Only do the -Sd step if really necessary. Pacman will warn you about a
>>> conflict in /lib on the -Su step if it is.
>>>
>>> If the "pacman -Su" step reports a conflict in /lib, you will need to
>>> look at all the files in /lib and determine which ones are not owned by
>>> glibc. This is achieved by "pacman -Qo /lib/*". You will need to move
>>
>> find /lib -print0 | xargs -o pacman -Qo
>> is much more effective at helping track down pesky files in
>> subdirectories (ala catalyst-hook).
>
> I figure that:
> error: cannot determine ownership of directory '/lib/foo' is a good
> hint, because these directories need removed too.

We probably need to add a note about looking for packages that own /lib
but seem to have no actual files in there (probably because the files
were manually moved to /usr/lib...). This will give a conflict on /lib.

So some sort of:
grep -R --include files "^lib" /var/lib/pacman/local/

I think the news announcement is probably getting a bit long given all
the esge cases that should be covered. I will just include instructions
for the ideal (usual?) case of "pacman -Syu --ignore glibc && pacman
-Su" and provide a link to a (as yet uncreated...) wiki page with
instructions on how to deal with conflicts.

Allan
 
Old 07-12-2012, 06:06 AM
Allan McRae
 
Default News item: /lib removal - Was: heads up: /lib removal

On 12/07/12 10:55, Allan McRae wrote:
> On 11/07/12 12:25, Allan McRae wrote:
>> On 11/07/12 11:32, Dan McGee wrote:
>>> On Tue, Jul 10, 2012 at 5:26 PM, Allan McRae <allan@archlinux.org> wrote:
>>>> A patched version of pacman is now in [testing] that will detect all the
>>>> issues reported so far that resulted in failed updates. Users of the
>>>> [testing] repo who last updated in the three days between the kmod
>>>> update and the glibc update may still run into issues, but "pacman -Sy
>>>> pacman && pacman -Su" will prevent that.
>>>>
>>>> Here is a (very draft) news item. I think it provides complete update
>>>> instructions for people using the "stable" repos.
>>>>
>>>>
>>>>
>>>> Removal of /lib directory
>>>>
>>>> All files in the /lib directory have been moved to /usr/lib and now /lib
>>>> is a symlink to usr/lib. During this update, pacman will identify a
>>>> conflict in the /lib directory. In the simplest case, this is worked
>>>> around by doing
>>>>
>>>> pacman -Syu --ignore glibc
>>>> pacman -Su
>>>>
>>>> When additional package depend on having a newer version of glibc than
>>>> is currently on your system and these also have files in /lib (e.g.
>>>> older versions of gcc), then and extra step will be necessary. For example:
>>>>
>>>> pacman -Syu --ignore glibc gcc
>>>> pacman -Sd gcc
>>>> pacman -Su
>>>>
>>>> Only do the -Sd step if really necessary. Pacman will warn you about a
>>>> conflict in /lib on the -Su step if it is.
>>>>
>>>> If the "pacman -Su" step reports a conflict in /lib, you will need to
>>>> look at all the files in /lib and determine which ones are not owned by
>>>> glibc. This is achieved by "pacman -Qo /lib/*". You will need to move
>>>
>>> find /lib -print0 | xargs -o pacman -Qo
>>> is much more effective at helping track down pesky files in
>>> subdirectories (ala catalyst-hook).
>>
>> I figure that:
>> error: cannot determine ownership of directory '/lib/foo' is a good
>> hint, because these directories need removed too.
>
> We probably need to add a note about looking for packages that own /lib
> but seem to have no actual files in there (probably because the files
> were manually moved to /usr/lib...). This will give a conflict on /lib.
>
> So some sort of:
> grep -R --include files "^lib" /var/lib/pacman/local/
>
> I think the news announcement is probably getting a bit long given all
> the esge cases that should be covered. I will just include instructions
> for the ideal (usual?) case of "pacman -Syu --ignore glibc && pacman
> -Su" and provide a link to a (as yet uncreated...) wiki page with
> instructions on how to deal with conflicts.
>


For comments:
https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib
 
Old 07-14-2012, 12:42 AM
Allan McRae
 
Default News item: /lib removal - Was: heads up: /lib removal

News draft

---

All files in the /lib directory have been moved to /usr/lib and now /lib
is a symlink to usr/lib. During this update, pacman will identify a
conflict in the /lib directory. In the simplest case, this is worked
around by doing

pacman -Syu --ignore glibc
pacman -Su

If either of this steps gives issues (e.g. dependency version issues,
file conflicts in /lib), refer to this
[guide](https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib) for
more detailed instructions on performing this upgrade.

---


I will post this soon and move the packages about a day later.

Allan
 
Old 07-14-2012, 01:10 AM
Allan McRae
 
Default News item: /lib removal - Was: heads up: /lib removal

On 14/07/12 10:42, Allan McRae wrote:
> News draft
>
> ---
>
> All files in the /lib directory have been moved to /usr/lib and now /lib
> is a symlink to usr/lib. During this update, pacman will identify a
> conflict in the /lib directory. In the simplest case, this is worked
> around by doing
>
> pacman -Syu --ignore glibc
> pacman -Su
>
> If either of this steps gives issues (e.g. dependency version issues,
> file conflicts in /lib), refer to this
> [guide](https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib) for
> more detailed instructions on performing this upgrade.
>
> ---
>
>
> I will post this soon and move the packages about a day later.
>


Packages to be moved:

[core/extra]
bash-completion
binutils
bitlbee
fcpci
fcpcmcia
glibc
kmod
linux
linux-lts
lirc
nvidia
nvidia-lts
syslog-ng
systemd

[community]
cdfs
dkms
libflashsupport-oss
ndiswrapper
open-vm-tools-modules
oss
r8168
r8168-lts
rsyslog
rt3562sta
systemd-arch-units
vhba-module
virtualbox
virtualbox-modules
virtualbox-modules-lts

[multilib]
lib32-glibc
 
Old 07-14-2012, 01:14 AM
Dave Reisner
 
Default News item: /lib removal - Was: heads up: /lib removal

On Sat, Jul 14, 2012 at 11:10:57AM +1000, Allan McRae wrote:
> On 14/07/12 10:42, Allan McRae wrote:
> > News draft
> >
> > ---
> >
> > All files in the /lib directory have been moved to /usr/lib and now /lib
> > is a symlink to usr/lib. During this update, pacman will identify a
> > conflict in the /lib directory. In the simplest case, this is worked
> > around by doing
> >
> > pacman -Syu --ignore glibc
> > pacman -Su
> >
> > If either of this steps gives issues (e.g. dependency version issues,
> > file conflicts in /lib), refer to this
> > [guide](https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib) for
> > more detailed instructions on performing this upgrade.
> >
> > ---
> >
> >
> > I will post this soon and move the packages about a day later.
> >
>
>
> Packages to be moved:
>
> [core/extra]
> bash-completion
> binutils
> bitlbee
> fcpci
> fcpcmcia
> glibc
> kmod
> linux
> linux-lts
> lirc
> nvidia
> nvidia-lts
> syslog-ng
> systemd

Also:

kdebase-workspace
xorg-xdm

both needed changes to their services for systemd-186.


>
> [community]
> cdfs
> dkms
> libflashsupport-oss
> ndiswrapper
> open-vm-tools-modules
> oss
> r8168
> r8168-lts
> rsyslog
> rt3562sta
> systemd-arch-units
> vhba-module
> virtualbox
> virtualbox-modules
> virtualbox-modules-lts
>
> [multilib]
> lib32-glibc
>
>
 

Thread Tools




All times are GMT. The time now is 04:28 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org