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_ima
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 'p
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
>>> pr
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 probl
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
On Aug 21, 2012 6:04 AM, "Christian Hesse" wrote:
>
> Paul Gideon Dann 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 thi
Paul Gideon Dann 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 thos
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 fi
Thomas Bächler 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
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 proble
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 c
On Thu, Jul 26, 2012 at 6:03 AM, Tom Gundersen wrote:
> On Thu, Jul 26, 2012 at 10:33 AM, C Anthony Risinger 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
On Thursday, July 26, 2012 12:50:47 PM Tom Gundersen wrote:
> On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik
>
> 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
On Thursday, July 26, 2012 10:56:37 AM Rodrigo Rivas wrote:
> On Thu, Jul 26, 2012 at 10:48 AM, 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
> > stuf
Op 26 jul. 2012 10:56 schreef "Rodrigo Rivas"
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-suppli
Christian Hesse on Thu, 2012/07/26 12:46:
> Christian Hesse on Thu, 2012/07/26 10:27:
> > Rodrigo Rivas on Thu, 2012/07/26 10:18:
> > > On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik
> > > wrote:
> > >
> > > > Why will /opt have to go?
> > > >
> > >
> > > Well, then:
> > >
> > > /opt ->
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 h
On Thu, Jul 26, 2012 at 10:33 AM, C Anthony Risinger 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
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik
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
Christian Hesse on Thu, 2012/07/26 10:27:
> Rodrigo Rivas on Thu, 2012/07/26 10:18:
> > On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik
> > wrote:
> >
> > > Why will /opt have to go?
> > >
> >
> > Well, then:
> >
> > /opt -> /usr/opt
> >
> > And everyone will be happy :)
> >
> > BTW, wil
Kevin Chadwick 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 bel
> »
> 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
>
> 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.
_
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
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?
The "advantage" is that you no longer can boot with a small root filesystem
Ian Fleming 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 tim
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
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
On Thu, Jul 26, 2012 at 10:48 AM, 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.
>
But then, /usr/local is for system administrat
> 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
On Thu, Jul 26, 2012 at 3:27 AM, Christian Hesse wrote:
> Rodrigo Rivas on Thu, 2012/07/26 10:18:
>> On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik
>> wrote:
>>
>> > Why will /opt have to go?
>> >
>>
>> Well, then:
>>
>> /opt -> /usr/opt
>>
>> And everyone will be happy :)
>>
>> BTW, will th
Rodrigo Rivas on Thu, 2012/07/26 10:18:
> On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik
> wrote:
>
> > 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?
G
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik
wrote:
> 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
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
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 folde
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
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
On Thu, Jul 26, 2012 at 8:01 AM, Oon-Ee Ng wrote:
> On Thu, Jul 26, 2012 at 11:30 AM, 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
On Thu, 2012-07-26 at 13:01 +0800, Oon-Ee Ng wrote:
> On Thu, Jul 26, 2012 at 11:30 AM, 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.
> >>
> >
On Thu, Jul 26, 2012 at 11:30 AM, 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
>> 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 fi
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 /us
> 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 shoul
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 que
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 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
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 tha
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 Arc
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
49 matches
Mail list logo
