Re: [arch-general] lib - usr/lib move, glibc and curl
Am 23.08.2012 05:28, schrieb Jayesh Badwaik: On Thursday 23 Aug 2012 01:28:58 Thomas Bächler wrote: BINARIES=pacman FILES=/etc/pacman.conf /etc/pacman.d/mirrorlist Then, edit /etc/mkinitcpio.d/linux.preset: Add: pacman_config=/etc/mkinitcpio-pacman.conf pacman_image=/boot/initramfs-linux-pacman.img and add 'pacman' to the PRESETS line. If this is done, would libcurl be automatically pulled into the initrd? Yes. But I forgot that you need to manually add gnupg. This requires at least /usr/bin/gnupg. This will only work if you download all packages beforehand, adding proper network support to initramfs is even more complicated. signature.asc Description: OpenPGP digital signature
Re: [arch-general] lib - usr/lib move, glibc and curl
pacman -Syud --ignore glibc and ended in a broken package manager. pacman is linked against libcurl, which is compiled against glibc 2.16.0 and includes versioned symbols. Luckily I had an old curl package around to temporarily fix the problem and update the system. Others may be out of luck, so... Do you think this needs some more investigation? This is known, and I don't think we can properly fix it, at least not anymore. How about adding pacman to the default failsafe initramfs. That way, if anything goes wrong with a big update like this, one could finish it up from that initramfs. -- дамјан
Re: [arch-general] lib - usr/lib move, glibc and curl
On 08/22/2012 03:54 PM, Damjan wrote: pacman -Syud --ignore glibc and ended in a broken package manager. pacman is linked against libcurl, which is compiled against glibc 2.16.0 and includes versioned symbols. Luckily I had an old curl package around to temporarily fix the problem and update the system. Others may be out of luck, so... Do you think this needs some more investigation? This is known, and I don't think we can properly fix it, at least not anymore. How about adding pacman to the default failsafe initramfs. That way, if anything goes wrong with a big update like this, one could finish it up from that initramfs. Feel free to do that yourself. I don't want my initrd's to be rescue images as well. And if I did, there'd be a whole bunch of other stuff I'd want too. I have at least one system where I only allocated 32 MB for /boot (my bad, but don't feel like fixing any time soon), and don't need the default initrd to grow. In fact, I've never had a problem that fallback would fix and would rather not even have it... I'd be in favor of a rescue hook though that someone may optionally add.
Re: [arch-general] lib - usr/lib move, glibc and curl
Am 23.08.2012 00:54, schrieb Damjan: pacman -Syud --ignore glibc and ended in a broken package manager. pacman is linked against libcurl, which is compiled against glibc 2.16.0 and includes versioned symbols. Luckily I had an old curl package around to temporarily fix the problem and update the system. Others may be out of luck, so... Do you think this needs some more investigation? This is known, and I don't think we can properly fix it, at least not anymore. How about adding pacman to the default failsafe initramfs. That way, if anything goes wrong with a big update like this, one could finish it up from that initramfs. Actually a neat idea. Copy mkinitcpio.conf to mkinitcpio-pacman.conf, add this in mkinitcpio-pacman.conf: BINARIES=pacman FILES=/etc/pacman.conf /etc/pacman.d/mirrorlist Then, edit /etc/mkinitcpio.d/linux.preset: Add: pacman_config=/etc/mkinitcpio-pacman.conf pacman_image=/boot/initramfs-linux-pacman.img and add 'pacman' to the PRESETS line. signature.asc Description: OpenPGP digital signature
Re: [arch-general] lib - usr/lib move, glibc and curl
On Thursday 23 Aug 2012 01:28:58 Thomas Bächler wrote: BINARIES=pacman FILES=/etc/pacman.conf /etc/pacman.d/mirrorlist Then, edit /etc/mkinitcpio.d/linux.preset: Add: pacman_config=/etc/mkinitcpio-pacman.conf pacman_image=/boot/initramfs-linux-pacman.img and add 'pacman' to the PRESETS line. If this is done, would libcurl be automatically pulled into the initrd? -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
[arch-general] lib - usr/lib move, glibc and curl
Hello everybody,
I just updated an old system and had to go through the lib - usr/lib move. I
did an
pacman -Syud --ignore glibc
and ended in a broken package manager. pacman is linked against libcurl,
which is compiled against glibc 2.16.0 and includes versioned symbols.
Luckily I had an old curl package around to temporarily fix the problem and
update the system.
Others may be out of luck, so... Do you think this needs some more
investigation?
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
Re: [arch-general] lib - usr/lib move, glibc and curl
Am 21.08.2012 10:25, schrieb Christian Hesse: pacman -Syud --ignore glibc and ended in a broken package manager. pacman is linked against libcurl, which is compiled against glibc 2.16.0 and includes versioned symbols. Luckily I had an old curl package around to temporarily fix the problem and update the system. Others may be out of luck, so... Do you think this needs some more investigation? This is known, and I don't think we can properly fix it, at least not anymore. signature.asc Description: OpenPGP digital signature
Re: [arch-general] lib - usr/lib move, glibc and curl
Thomas Bächler tho...@archlinux.org on Tue, 2012/08/21 10:43:
Am 21.08.2012 10:25, schrieb Christian Hesse:
pacman -Syud --ignore glibc
and ended in a broken package manager. pacman is linked against libcurl,
which is compiled against glibc 2.16.0 and includes versioned symbols.
Luckily I had an old curl package around to temporarily fix the problem
and update the system.
Others may be out of luck, so... Do you think this needs some more
investigation?
This is known, and I don't think we can properly fix it, at least not
anymore.
Oh, the commands in the wiki exclude curl now. Did not notice that.
I am fine with the situation, I can deal with these things. Hopefully others
will read the wiki. :D
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
signature.asc
Description: PGP signature
Re: [arch-general] lib - usr/lib move, glibc and curl
On Tuesday 21 Aug 2012 11:05:07 Christian Hesse wrote: Oh, the commands in the wiki exclude curl now. Did not notice that. I am fine with the situation, I can deal with these things. Hopefully others will read the wiki. :D For those like me that followed the news article's instructions first and ran into the curl issue, I fixed this by coping the old curl package (that was just replaced) from /var/cache/pacman/pkg into an empty subdirectory in my home directory and unpacked it. Then, as root I replaced the /usr/lib/libcurl.so.4.2.0 library with the one found in the package. This fixed pacman, allowing me to downgrade curl properly with pacman -U. The rest can then be done as described on the wiki page. Paul
Re: [arch-general] lib - usr/lib move, glibc and curl
Paul Gideon Dann pdgid...@gmail.com on Tue, 2012/08/21 11:01:
On Tuesday 21 Aug 2012 11:05:07 Christian Hesse wrote:
Oh, the commands in the wiki exclude curl now. Did not notice that.
I am fine with the situation, I can deal with these things. Hopefully
others will read the wiki. :D
For those like me that followed the news article's instructions first and
ran into the curl issue, I fixed this by coping the old curl package (that
was just replaced) from /var/cache/pacman/pkg into an empty subdirectory in
my home directory and unpacked it. Then, as root I replaced the
/usr/lib/libcurl.so.4.2.0 library with the one found in the package. This
fixed pacman, allowing me to downgrade curl properly with pacman -U.
The rest can then be done as described on the wiki page.
That is exactly what I did. ;)
And do not forget to reinstall curl to have the recent version in place.
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
Re: [arch-general] lib - usr/lib move, glibc and curl
On Aug 21, 2012 6:04 AM, Christian Hesse l...@eworm.de wrote:
Paul Gideon Dann pdgid...@gmail.com on Tue, 2012/08/21 11:01:
On Tuesday 21 Aug 2012 11:05:07 Christian Hesse wrote:
Oh, the commands in the wiki exclude curl now. Did not notice that.
I am fine with the situation, I can deal with these things. Hopefully
others will read the wiki. :D
For those like me that followed the news article's instructions first
and
ran into the curl issue, I fixed this by coping the old curl package
(that
was just replaced) from /var/cache/pacman/pkg into an empty
subdirectory in
my home directory and unpacked it. Then, as root I replaced the
/usr/lib/libcurl.so.4.2.0 library with the one found in the package.
This
fixed pacman, allowing me to downgrade curl properly with pacman -U.
The rest can then be done as described on the wiki page.
That is exactly what I did. ;)
And do not forget to reinstall curl to have the recent version in place.
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:
*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig
*/b/42*2-3)*42);}
You could have untared the old package into an empty directory, then from a
root shell used LD_PRELOAD=/path/to/old/libcurl.so pacman -Su
Re: [arch-general] lib - usr/lib
On Wed, Jul 25, 2012 at 11:30:06PM -0400, brainwor...@lavabit.com wrote: If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in. well no the point is to have a single top-level directory for a single purpose. so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state). My variant is: /lib - /usr/lib /bin - /usr/bin /sbin - /usr/bin After that rename: /usr to /system /etc to /config /dev to /device Why not using clear (and not so short) names to indicate real purpose! Things are tried and true... But things have changed alot in recent years. For example network/internet bandwidth or the size and speed of storage medium. AND re-naming things is not keeping it simple... or is it? No its not.. So... =)
Re: [arch-general] lib - usr/lib
On Thursday 26 Jul 2012 05:13:39 Damjan wrote: If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in. well no the point is to have a single top-level directory for a single purpose. so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state). Let me paste this here: » The merged directory /usr, containing almost the entire vendor- supplied operating system resources, offers us a number of new features regarding OS snapshotting and options for enterprise environments for network sharing or running multiple guests on one host. Most of this is much harder to accomplish, or even impossible, with the current arbitrary split of tools across multiple directories. With all vendor-supplied OS resources in a single directory /usr they may be shared atomically, snapshots of them become atomic, and the file system may be made read-only as a single unit. « Well, /opt would have to go soon, too Why will /opt have to go? I always though /opt was for installing custom software which you do not want to mix with other software (for example I have MATLAB and similar stuff installed there with each of them in its separate folder) and I guess, that is the one and only use of /opt and there is no other directory which does something similar, except for if you are talking about /local but then, /local has the purpose of being /local, it can be vendor- supplied local program which are specific to the machine and it will have /bin /etc /lib and stuff? -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Re: [arch-general] lib - usr/lib
On Thu, 2012-07-26 at 12:23 +0530, Jayesh Badwaik wrote: Why will /opt have to go? I always though /opt was for installing custom software which you do not want to mix with other software (for example I have MATLAB and similar stuff installed there with each of them in its separate folder) and I guess, that is the one and only use of /opt and there is no other directory which does something similar, except for if you are talking about /local but then, /local has the purpose of being /local, it can be vendor- supplied local program which are specific to the machine and it will have /bin /etc /lib and stuff? Good point! Assumed I wish to use software Xy version 1 and I want to install Xy version alpha 2 too? Until now /opt is the place to do so.
Re: [arch-general] lib - usr/lib
On Thu, 2012-07-26 at 09:09 +0200, Ralf Mardorf wrote: On Thu, 2012-07-26 at 12:23 +0530, Jayesh Badwaik wrote: Why will /opt have to go? I always though /opt was for installing custom software which you do not want to mix with other software (for example I have MATLAB and similar stuff installed there with each of them in its separate folder) and I guess, that is the one and only use of /opt and there is no other directory which does something similar, except for if you are talking about /local but then, /local has the purpose of being /local, it can be vendor- supplied local program which are specific to the machine and it will have /bin /etc /lib and stuff? Good point! Assumed I wish to use software Xy version 1 and I want to install Xy version alpha 2 too? Until now /opt is the place to do so. PS: /local isn't the right place to install one of two different versions of the same software! This will cause conflicts!
Re: [arch-general] lib - usr/lib
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik jayesh.badwai...@gmail.comwrote: Why will /opt have to go? Well, then: /opt - /usr/opt And everyone will be happy :) BTW, will there be the move from /bin to /usr/bin in the foreseeable future? -- Rodrigo
Re: [arch-general] lib - usr/lib
Rodrigo Rivas rodrigorivasco...@gmail.com on Thu, 2012/07/26 10:18:
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik
jayesh.badwai...@gmail.comwrote:
Why will /opt have to go?
Well, then:
/opt - /usr/opt
And everyone will be happy :)
BTW, will there be the move from /bin to /usr/bin in the foreseeable future?
Good question. I can not remember having seen and recent plans on it.
This gives an idea about which packages still have files in /bin/:
$ pacman -Qoq /bin/* | sort | uniq
And the same for /sbin/:
$ pacman -Qoq /sbin/* | sort | uniq
No single file that does not belong to a package here... Good conditions for a
smooth update. ;)
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
Re: [arch-general] lib - usr/lib
On Thu, Jul 26, 2012 at 3:27 AM, Christian Hesse l...@eworm.de wrote: Rodrigo Rivas rodrigorivasco...@gmail.com on Thu, 2012/07/26 10:18: On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik jayesh.badwai...@gmail.comwrote: Why will /opt have to go? Well, then: /opt - /usr/opt And everyone will be happy :) BTW, will there be the move from /bin to /usr/bin in the foreseeable future? Good question. I can not remember having seen and recent plans on it. This gives an idea about which packages still have files in /bin/: $ pacman -Qoq /bin/* | sort | uniq And the same for /sbin/: $ pacman -Qoq /sbin/* | sort | uniq No single file that does not belong to a package here... Good conditions for a smooth update. ;) i've got nothing to back this up, but i'm guessing this one is going to be a little trickier ... mainly because there are multiple packages that are *expected* to exist in /bin. `bash` (sh) and `coreutils` are the two major ones that come to mind. i expect pacman does not fork out to external processes, and can handle the switch itself, but it's not as easy as the incremental lib - usr/lib update (which affects nothing) ... i expect there will be a final switcharoo at the end where 2+ packages must all be moved in one fell swoop. Tom? others? i too am curious of the progress or experiences thus far. -- C Anthony
Re: [arch-general] lib - usr/lib
Well, then: /opt - /usr/opt And everyone will be happy :) No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict. -- Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Re: [arch-general] lib - usr/lib
On Thu, Jul 26, 2012 at 10:48 AM, Jayesh Badwaik jayesh.badwai...@gmail.com wrote: Well, then: /opt - /usr/opt And everyone will be happy :) No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict. But then, /usr/local is for system administrator stuff, so what about? /opt - /usr/local/opt /usr/local - /local Just half kidding!
Re: [arch-general] lib - usr/lib
On Thu, 2012-07-26 at 14:18 +0530, Jayesh Badwaik wrote: Well, then: /opt - /usr/opt And everyone will be happy :) No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict. I need to go back to the future, sorry, back to the past /media/maverick/usr/local/bin ... Personal stuff was in /usr/local ;). Special stuff still is in /opt, e.g. /media/avlinux/opt/Ardour-3.0beta1a_10644-dbg Pff ;) ... :p Ralf
Re: [arch-general] lib - usr/lib
On Thursday 26 Jul 2012 11:12:34 Ralf Mardorf wrote: On Thu, 2012-07-26 at 14:18 +0530, Jayesh Badwaik wrote: Well, then: /opt - /usr/opt And everyone will be happy :) No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict. I need to go back to the future, sorry, back to the past /media/maverick/usr/local/bin ... Personal stuff was in /usr/local ;). Special stuff still is in /opt, e.g. /media/avlinux/opt/Ardour-3.0beta1a_10644-dbg Pff ;) ... :p Ralf Ohh right, dear me. By personal ofcourse, I meant, special to the user of the computer. Not personal files. Not a good time for me writing mails I guess. I already made more errors elsewhere, readying myself for a barraged flame now! -- Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Re: [arch-general] lib - usr/lib
Ian Fleming itremm...@gmail.com wrote: I beleive its a question of How is the filesytem structure and its distributed nature/capabilities relevant today i.e the need for /bin or /lib even. /bin has been removed in 1987 already - in favor of a symlink to /usr/bin and a few programs in the (at that time) newly created /sbin. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] lib - usr/lib
Ken CC ken.c...@gmail.com wrote: On Tue, Jul 24, 2012 at 09:48:00PM +0200, Ralf Mardorf wrote: I laugh away this trouble. Is there any information about the advantages of lib - usr/lib? anyone likes to answer this question? The advantage is that you no longer can boot with a small root filesystem and later mount /usr. So this change is a questionable change. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] lib - usr/lib
Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Thu, 2012-07-26 at 14:18 +0530, Jayesh Badwaik wrote: Well, then: /opt - /usr/opt And everyone will be happy :) No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict. I need to go back to the future, sorry, back to the past /media/maverick/usr/local/bin ... Personal stuff was in /usr/local ;). /usr/local was abandoned in 1987 already. In former times all non-admin binaries have ben in /bin. Then /usr/bin was created (world writable) for personal binaries of general interest. Steve Bourne soon discovered that these binaries have been of low quality and wrote a cron script that checked each day whether the documentation was as recent as the binaries and otherwise removed the new binaries. This is why we have usable documentaion on UNIX. Later /usr/bin was hijacked by the system and people created /usr/local. In 1987, all UNIX vendors decided that /usr/local is not useful as it causes more problems (from e.g. name space clashes) than it solves and /usr/local was abbandoned in favor of /opt/packet/bin. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] lib - usr/lib
Why will /opt have to go? I think he meant it will have to leave root. It should have been under /usr like /usr/local in the first place. -- Why not do something good every day and install BOINC.
Re: [arch-general] lib - usr/lib
» The merged directory /usr, containing almost the entire vendor-supplied operating system resources, offers us a number of new features regarding OS snapshotting and options for enterprise environments for network sharing or running multiple guests on one host. Most of this is much harder to accomplish, or even impossible, with the current arbitrary split of tools across multiple directories. With all vendor-supplied OS resources in a single directory /usr they may be shared atomically, snapshots of them become atomic, and the file system may be made read-only as a single unit. « hmmm, I think I've brought this up before and forgotten the response, something along the lines of they are not static anymore anyway. They are atleast majoratively on OpenBSD. I believe /bin, /sbin aka the root, etc. traditionally contained static binaries so you would have a highly reliable working core system with just say a 50 Mb / partition that you could easily hack and restore and rarely remount for example. I welcome the read-only root though and I haven't looked and forget some of the complexities at play. -- Why not do something good every day and install BOINC.
Re: [arch-general] lib - usr/lib
Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: hmmm, I think I've brought this up before and forgotten the response, something along the lines of they are not static anymore anyway. They are atleast majoratively on OpenBSD. *BSD ignored most FHS agreements from 1987 and unfortunately Linux followed this. I believe /bin, /sbin aka the root, etc. traditionally contained static binaries so you would have a highly reliable working core system with just say a 50 Mb / partition that you could easily hack and restore and rarely remount for example. See my recent post for the real historical background. /sbin was created for SunOS-4.0 for the few (at that time static) binaries that are needed in order to bootstrap the multi-user mode. At the same time, /usr/etc was renamed to /usr/sbin. I welcome the read-only root though and I haven't looked and forget some of the complexities at play. There have been some other changes before 1987, that allowed to have /usr read-only - as required by the berkely nd driver that introduced the ability to boot diskless clients. These changes however have been introduced as a hack and many symlinks have been introduced to work around files that have been on /usr but need to be writable (e.g. /usr/spool). With SunOS-4.0 and the FHS UNIX summit in 1987, /var and /opt have been introduced. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] lib - usr/lib
Christian Hesse l...@eworm.de on Thu, 2012/07/26 10:27:
Rodrigo Rivas rodrigorivasco...@gmail.com on Thu, 2012/07/26 10:18:
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik
jayesh.badwai...@gmail.comwrote:
Why will /opt have to go?
Well, then:
/opt - /usr/opt
And everyone will be happy :)
BTW, will there be the move from /bin to /usr/bin in the foreseeable
future?
Good question. I can not remember having seen and recent plans on it.
This gives an idea about which packages still have files in /bin/:
$ pacman -Qoq /bin/* | sort | uniq
And the same for /sbin/:
$ pacman -Qoq /sbin/* | sort | uniq
No single file that does not belong to a package here... Good conditions
for a smooth update. ;)
That said i still have two files linked from /usr/sbin/ to /sbin/...
/usr/sbin/dhcpcd - /sbin/dhcpcd
/usr/sbin/ip - /sbin/ip
When are these supposed to go away or completely moved to /usr/?
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
Re: [arch-general] lib - usr/lib
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik jayesh.badwai...@gmail.com wrote: Why will /opt have to go? I don't think we will ever manage to get rid of /opt. However, if we were to follow brainworker's renaming scheme I'd suggest /opt to /crap Should make it clear what kind of packages belong there ;-) -t
Re: [arch-general] lib - usr/lib
On Thu, Jul 26, 2012 at 10:33 AM, C Anthony Risinger anth...@xtfx.me wrote: i've got nothing to back this up, but i'm guessing this one is going to be a little trickier ... mainly because there are multiple packages that are *expected* to exist in /bin. `bash` (sh) and `coreutils` are the two major ones that come to mind. i expect pacman does not fork out to external processes, and can handle the switch itself, but it's not as easy as the incremental lib - usr/lib update (which affects nothing) ... i expect there will be a final switcharoo at the end where 2+ packages must all be moved in one fell swoop. Tom? others? i too am curious of the progress or experiences thus far. This was the original proposal: http://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html. I just re-read it, noticing that I wrote about the move of /lib that it has no real risks or downsides. Feel free to point and laugh. I have a patch against pacman which should make it able to deal with /bin/sh being in /usr/bin/, which I think is the only issue before we could make such a move (as pacman does call sh to run post-upgrade scripts and similar). I guess no one is in any hurry to make this move though, people probably want to catch their breath after the /lib move ;-) Cheers, Tom
Re: [arch-general] lib - usr/lib
On Thursday 26 Jul 2012 12:50:47 Tom Gundersen wrote: I don't think we will ever manage to get rid of /opt. However, if we were to follow brainworker's renaming scheme I'd suggest /opt to /crap Should make it clear what kind of packages belong there ;-) ;-) -- Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Re: [arch-general] lib - usr/lib
Christian Hesse l...@eworm.de on Thu, 2012/07/26 12:46:
Christian Hesse l...@eworm.de on Thu, 2012/07/26 10:27:
Rodrigo Rivas rodrigorivasco...@gmail.com on Thu, 2012/07/26 10:18:
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik
jayesh.badwai...@gmail.comwrote:
Why will /opt have to go?
Well, then:
/opt - /usr/opt
And everyone will be happy :)
BTW, will there be the move from /bin to /usr/bin in the foreseeable
future?
Good question. I can not remember having seen and recent plans on it.
This gives an idea about which packages still have files in /bin/:
$ pacman -Qoq /bin/* | sort | uniq
And the same for /sbin/:
$ pacman -Qoq /sbin/* | sort | uniq
No single file that does not belong to a package here... Good conditions
for a smooth update. ;)
That said i still have two files linked from /usr/sbin/ to /sbin/...
/usr/sbin/dhcpcd - /sbin/dhcpcd
/usr/sbin/ip - /sbin/ip
When are these supposed to go away or completely moved to /usr/?
I was wrong, there are some more:
/bin/ping6 - /usr/bin/ping6
/bin/awk - gawk
/bin/gawk - /usr/bin/gawk
/bin/ping - /usr/bin/ping
/bin/hostname - /usr/bin/hostname
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
Re: [arch-general] lib - usr/lib
Op 26 jul. 2012 10:56 schreef Rodrigo Rivas rodrigorivasco...@gmail.com het volgende: On Thu, Jul 26, 2012 at 10:48 AM, Jayesh Badwaik jayesh.badwai...@gmail.com wrote: Well, then: /opt - /usr/opt And everyone will be happy :) No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict. But then, /usr/local is for system administrator stuff, so what about? close, but no cookie. /usr/local is for locally compiled stuff where no packages are used (sysadmin!). Also, these should adhere to the Unix standards for file locations (binaries, libraries, config, etc) /opt is for third-party stuff like closed-source software. The idea is to let each such application have it's own hierarchie without cluttering the rest of the system. mvg, Guus
Re: [arch-general] lib - usr/lib
On Thursday, July 26, 2012 10:56:37 AM Rodrigo Rivas wrote: On Thu, Jul 26, 2012 at 10:48 AM, Jayesh Badwaik jayesh.badwai...@gmail.com wrote: Well, then: /opt - /usr/opt And everyone will be happy :) No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict. But then, /usr/local is for system administrator stuff, so what about? /opt - /usr/local/opt /usr/local - /local Just half kidding! Well then /usr/lib - /lib /usr/lib64 - /lib64 /usr/bin -/bin /usr/local/opt /opt That should do it ;)
Re: [arch-general] lib - usr/lib
On Thursday, July 26, 2012 12:50:47 PM Tom Gundersen wrote: On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik jayesh.badwai...@gmail.com wrote: Why will /opt have to go? I don't think we will ever manage to get rid of /opt. However, if we were to follow brainworker's renaming scheme I'd suggest /opt to /crap Should make it clear what kind of packages belong there ;-) -t Hey now we are making progress
Re: [arch-general] lib - usr/lib
On Thu, Jul 26, 2012 at 6:03 AM, Tom Gundersen t...@jklm.no wrote:
On Thu, Jul 26, 2012 at 10:33 AM, C Anthony Risinger anth...@xtfx.me wrote:
i've got nothing to back this up, but i'm guessing this one is going
to be a little trickier ... mainly because there are multiple packages
that are *expected* to exist in /bin. `bash` (sh) and `coreutils` are
the two major ones that come to mind.
i expect pacman does not fork out to external processes, and can
handle the switch itself, but it's not as easy as the incremental lib
- usr/lib update (which affects nothing) ... i expect there will be a
final switcharoo at the end where 2+ packages must all be moved in one
fell swoop.
Tom? others? i too am curious of the progress or experiences thus far.
This was the original proposal:
http://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html.
I just re-read it, noticing that I wrote about the move of /lib that
it has no real risks or downsides. Feel free to point and laugh.
I have a patch against pacman which should make it able to deal with
/bin/sh being in /usr/bin/, which I think is the only issue before we
could make such a move (as pacman does call sh to run post-upgrade
scripts and similar).
I guess no one is in any hurry to make this move though, people
probably want to catch their breath after the /lib move ;-)
heh, yeah i'm sure you're right about that :-)
this might be slightly hacky, but what if packages were moved one at a
time, and each time the `filesystem` package grew symlinks from
`/bin/{some-binary}` - `/usr/bin/{some-binary}`? then, when /bin has
nothing but symlinks, you can upgrade the filesystem package, dropping
all the link and replacing `/bin` with symlinks to `/usr/bin`.
it would be a little ugly, with filesystem absobing some 200+ links,
but nothing work break in the interim (i think ;-).
--
C Anthony
Re: [arch-general] lib - usr/lib
On Tue, Jul 24, 2012 at 09:48:00PM +0200, Ralf Mardorf wrote: I laugh away this trouble. Is there any information about the advantages of lib - usr/lib? anyone likes to answer this question? -ken
Re: [arch-general] lib - usr/lib
On Thu, Jul 26, 2012 at 09:19:59AM +0800, Ken CC wrote: On Tue, Jul 24, 2012 at 09:48:00PM +0200, Ralf Mardorf wrote: I laugh away this trouble. Is there any information about the advantages of lib - usr/lib? anyone likes to answer this question? -ken this was the thread on arch-dev-public talking about it http://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html pgp9as1Rn1os5.pgp Description: PGP signature
Re: [arch-general] lib - usr/lib
On Thu, Jul 26, 2012 at 09:19:59AM +0800, Ken CC wrote: On Tue, Jul 24, 2012 at 09:48:00PM +0200, Ralf Mardorf wrote: I laugh away this trouble. Is there any information about the advantages of lib - usr/lib? anyone likes to answer this question? -ken I beleive its a question of How is the filesytem structure and its distributed nature/capabilities relevant today i.e the need for /bin or /lib even.
Re: [arch-general] lib - usr/lib
I beleive its a question of How is the filesytem structure and its distributed nature/capabilities relevant today i.e the need for /bin or /lib even. If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in. pgpWRVjoqtovB.pgp Description: PGP signature
Re: [arch-general] lib - usr/lib
If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in. well no the point is to have a single top-level directory for a single purpose. so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state). Let me paste this here: » The merged directory /usr, containing almost the entire vendor-supplied operating system resources, offers us a number of new features regarding OS snapshotting and options for enterprise environments for network sharing or running multiple guests on one host. Most of this is much harder to accomplish, or even impossible, with the current arbitrary split of tools across multiple directories. With all vendor-supplied OS resources in a single directory /usr they may be shared atomically, snapshots of them become atomic, and the file system may be made read-only as a single unit. « Well, /opt would have to go soon, too -- дамјан
Re: [arch-general] lib - usr/lib
If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in. well no the point is to have a single top-level directory for a single purpose. so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state). My variant is: /lib - /usr/lib /bin - /usr/bin /sbin - /usr/bin After that rename: /usr to /system /etc to /config /dev to /device Why not using clear (and not so short) names to indicate real purpose!
Re: [arch-general] lib - usr/lib
On Thu, Jul 26, 2012 at 11:30 AM, brainwor...@lavabit.com wrote: If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in. well no the point is to have a single top-level directory for a single purpose. so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state). My variant is: /lib - /usr/lib /bin - /usr/bin /sbin - /usr/bin After that rename: /usr to /system /etc to /config /dev to /device Why not using clear (and not so short) names to indicate real purpose! Yes, why not just turn the device into android... renaming for the sake of renaming serves no purpose. There are real benefits to moving /lib and /bin into /usr, renaming folders does not provide any real benefits.
Re: [arch-general] lib - usr/lib
On Thu, 2012-07-26 at 13:01 +0800, Oon-Ee Ng wrote: On Thu, Jul 26, 2012 at 11:30 AM, brainwor...@lavabit.com wrote: If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in. well no the point is to have a single top-level directory for a single purpose. so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state). My variant is: /lib - /usr/lib /bin - /usr/bin /sbin - /usr/bin After that rename: /usr to /system /etc to /config /dev to /device Why not using clear (and not so short) names to indicate real purpose! Yes, why not just turn the device into android... renaming for the sake of renaming serves no purpose. There are real benefits to moving /lib and /bin into /usr, renaming folders does not provide any real benefits. Today I hope we'll keep /usr, /etc, /dev etc., but when I started to use Linux /system, /config would be easier to understand. Well, between /dev and /device there's no difference, even for my completely broken English. However, I'm not sure if brainworker is serious or sarcastic ;p. Regards, Ralf
Re: [arch-general] lib - usr/lib
On Thu, Jul 26, 2012 at 8:01 AM, Oon-Ee Ng ngoonee.t...@gmail.com wrote: On Thu, Jul 26, 2012 at 11:30 AM, brainwor...@lavabit.com wrote: If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in. well no the point is to have a single top-level directory for a single purpose. so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state). My variant is: /lib - /usr/lib /bin - /usr/bin /sbin - /usr/bin After that rename: /usr to /system /etc to /config /dev to /device Why not using clear (and not so short) names to indicate real purpose! Yes, why not just turn the device into android... renaming for the sake of renaming serves no purpose. There are real benefits to moving /lib and /bin into /usr, renaming folders does not provide any real benefits. Actually, having more descriptive names would ease the burden on the new users... Leading to less confusion and less mailing list posts regarding where they need to look for config files. Of course, this will also mean a lot of nitpicking regarding what the symlinks should be named... M
[arch-general] lib - usr/lib
I laugh away this trouble. Is there any information about the advantages of lib - usr/lib? I like to read it, after I finished the following occupational therapy [1]. I suspect that if I won't do it now, I have to restore my Arch from a backup? Or can I shutdown and startup anyway? Regards, Ralf [1] [root@archlinux spinymouse]# pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (1): glibc-2.16.0-2 Total Installed Size: 37.58 MiB Net Upgrade Size: 0.83 MiB Proceed with installation? [Y/n] (1/1) checking package integrity [##] 100% (1/1) loading package files [##] 100% (1/1) checking for file conflicts [##] 100% error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. [root@archlinux spinymouse]# grep '^lib/' /var/lib/pacman/local/*/files /var/lib/pacman/local/glibc-2.15-12/files:lib/ /var/lib/pacman/local/glibc-2.15-12/files:lib/ld-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/ld-linux-x86-64.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libBrokenLocale-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libBrokenLocale.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libSegFault.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libanl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libanl.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libc-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libc.so.6 /var/lib/pacman/local/glibc-2.15-12/files:lib/libcidn-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libcidn.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libcrypt-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libcrypt.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libdl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libdl.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libm-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libm.so.6 /var/lib/pacman/local/glibc-2.15-12/files:lib/libmemusage.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnsl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnsl.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_compat-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_compat.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_db-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_db.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_dns-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_dns.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_files-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_files.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_hesiod-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_hesiod.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nis-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nis.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nisplus-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nisplus.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libpcprofile.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libpthread-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libpthread.so.0 /var/lib/pacman/local/glibc-2.15-12/files:lib/libresolv-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libresolv.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/librt-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/librt.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libthread_db-1.0.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libthread_db.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libutil-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libutil.so.1 /var/lib/pacman/local/ld-lsb-3-3/files:lib/ /var/lib/pacman/local/ld-lsb-3-3/files:lib/ld-lsb.so.3 /var/lib/pacman/local/udev-compat-180-1/files:lib/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/autofs /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/btrfs-control /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/cpu/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/cpu/microcode /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/fuse /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/mapper/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/mapper/control /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/net/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/net/tun /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/ppp /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/snd/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/snd/seq
Re: [arch-general] lib - usr/lib
On Tue, Jul 24, 2012 at 09:48:00PM +0200, Ralf Mardorf wrote: I laugh away this trouble. Is there any information about the advantages of lib - usr/lib? I like to read it, after I finished the following occupational therapy [1]. I suspect that if I won't do it now, I have to restore my Arch from a backup? Or can I shutdown and startup anyway? Regards, Ralf [1] [root@archlinux spinymouse]# pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (1): glibc-2.16.0-2 Total Installed Size: 37.58 MiB Net Upgrade Size: 0.83 MiB Proceed with installation? [Y/n] (1/1) checking package integrity [##] 100% (1/1) loading package files [##] 100% (1/1) checking for file conflicts [##] 100% error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. [root@archlinux spinymouse]# grep '^lib/' /var/lib/pacman/local/*/files /var/lib/pacman/local/glibc-2.15-12/files:lib/ /var/lib/pacman/local/glibc-2.15-12/files:lib/ld-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/ld-linux-x86-64.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libBrokenLocale-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libBrokenLocale.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libSegFault.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libanl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libanl.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libc-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libc.so.6 /var/lib/pacman/local/glibc-2.15-12/files:lib/libcidn-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libcidn.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libcrypt-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libcrypt.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libdl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libdl.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libm-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libm.so.6 /var/lib/pacman/local/glibc-2.15-12/files:lib/libmemusage.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnsl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnsl.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_compat-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_compat.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_db-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_db.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_dns-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_dns.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_files-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_files.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_hesiod-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_hesiod.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nis-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nis.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nisplus-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nisplus.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libpcprofile.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libpthread-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libpthread.so.0 /var/lib/pacman/local/glibc-2.15-12/files:lib/libresolv-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libresolv.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/librt-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/librt.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libthread_db-1.0.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libthread_db.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libutil-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libutil.so.1 /var/lib/pacman/local/ld-lsb-3-3/files:lib/ /var/lib/pacman/local/ld-lsb-3-3/files:lib/ld-lsb.so.3 /var/lib/pacman/local/udev-compat-180-1/files:lib/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/autofs /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/btrfs-control /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/cpu/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/cpu/microcode /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/fuse /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/mapper/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/mapper/control /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/net/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/net/tun /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/ppp
Re: [arch-general] lib - usr/lib
On Tue, 2012-07-24 at 15:52 -0400, Daniel Wallace wrote: remove udev-compat it is old, either update ld-lsb from aur or remove it as for the find, remove any un owned files from anything under /lib. then remove any empty directories then update Thank you :) at least it's not bad that I'm forced to get rid of some old unneeded stuff ;). Regards, Ralf
