Reindl Harald wrote:
Am 15.02.2012 13:43, schrieb Martin Langhoff:
On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net
mailto:h.rei...@thelounge.net wrote:
there is no single reason for a feature like /usrmove which
in fact nobody NEEDS at all and definitly not now to press
it into
On Thu, 2012-02-16 at 13:22 +0100, Jim Meyering wrote:
Reindl Harald wrote:
Am 15.02.2012 13:43, schrieb Martin Langhoff:
On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net
mailto:h.rei...@thelounge.net wrote:
there is no single reason for a feature like /usrmove which
in
Simo Sorce wrote:
On Thu, 2012-02-16 at 13:22 +0100, Jim Meyering wrote:
...
Prior to F17, I've always put /usr on a partition separate from /.
$ df -hT / /usr
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda4 ext4 11G 7.3G 3.2G 70% /
/dev/sda6
SS == Simo Sorce s...@redhat.com writes:
SS I guess it is time to change habits, what's the point of a separate
SS /usr these days ?
I also always configured a separate /usr until I decided to obey
systemd's complaints about it being broken (though of course I never had
any issue at all with
On Wed, Feb 15, 2012 at 1:26 AM, Kevin Kofler kevin.kof...@chello.at wrote:
Lennart Poettering wrote:
Because dropping these dirs from the search paths is merely an
optimization, not a requirement.
You call it an optimization, I call it fixing a pessimization (performance
regression).
And
On 02/15/2012 10:37 AM, drago01 wrote:
On Wed, Feb 15, 2012 at 1:26 AM, Kevin Koflerkevin.kof...@chello.at wrote:
Lennart Poettering wrote:
Because dropping these dirs from the search paths is merely an
optimization, not a requirement.
You call it an optimization, I call it fixing a
On Wed, Feb 15, 2012 at 11:18 AM, Ralf Corsepius rc040...@freenet.de wrote:
On 02/15/2012 10:37 AM, drago01 wrote:
On Wed, Feb 15, 2012 at 1:26 AM, Kevin Koflerkevin.kof...@chello.at
wrote:
Lennart Poettering wrote:
Because dropping these dirs from the search paths is merely an
Am 15.02.2012 11:25, schrieb drago01:
So? Should we drop all features that aren't bug free after feature freeze?
Yes. We've forked f17 and you guys are still chasing elementary bugs.
elementary bugs ? You got to be either kidding or trolling.
What do you expect Fedora users to think of
Am 15.02.2012 11:20 schrieb Ralf Corsepius rc040...@freenet.de:
Yes. We've forked f17 and you guys are still chasing elementary bugs.
What do you expect Fedora users to think of this? It communicates a nice
impression of the quality of your works.
Better stop this non-sense now
rofl...
On 15/02/12 10:18, Ralf Corsepius wrote:
So? Should we drop all features that aren't bug free after feature
freeze?
Yes. We've forked f17 and you guys are still chasing elementary bugs.
What do you expect Fedora users to think of this? It communicates a nice
impression of the quality of your
Am 15.02.2012 12:05, schrieb Harald Hoyer:
Am 15.02.2012 11:20 schrieb Ralf Corsepius rc040...@freenet.de
mailto:rc040...@freenet.de:
Yes. We've forked f17 and you guys are still chasing elementary bugs.
What do you expect Fedora users to think of this? It communicates a nice
impression
On Wed, Feb 15, 2012 at 12:16:07PM +0100, Reindl Harald wrote:
there is no single reason for a feature like /usrmove which
in fact nobody NEEDS at all and definitly not now to press
it into the next release with pressure
Well, I need usrmove, because I have a strong need for clean system.
Am 15.02.2012 12:24, schrieb Tomasz Torcz:
On Wed, Feb 15, 2012 at 12:16:07PM +0100, Reindl Harald wrote:
there is no single reason for a feature like /usrmove which
in fact nobody NEEDS at all and definitly not now to press
it into the next release with pressure
Well, I need usrmove,
On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net wrote:
there is no single reason for a feature like /usrmove which
in fact nobody NEEDS at all and definitly not now to press
it into the next release with pressure
You are wrong. The /usr move has a very clear impact in being able
Am 15.02.2012 13:43, schrieb Martin Langhoff:
On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net
mailto:h.rei...@thelounge.net wrote:
there is no single reason for a feature like /usrmove which
in fact nobody NEEDS at all and definitly not now to press
it into the next release
On Wed, Feb 15, 2012 at 1:43 PM, Martin Langhoff
martin.langh...@gmail.com wrote:
You are wrong. The /usr move has a very clear impact in being able to
snapshot your OS install partition. Add btrfs, yum hooks and the
already-implemented stateless configuration and you have a really major
Am 15.02.2012 14:25, schrieb Miloslav Trmač:
On Wed, Feb 15, 2012 at 1:43 PM, Martin Langhoff
martin.langh...@gmail.com wrote:
You are wrong. The /usr move has a very clear impact in being able to
snapshot your OS install partition. Add btrfs, yum hooks and the
already-implemented stateless
On Wed, Feb 15, 2012 at 8:30 AM, Reindl Harald h.rei...@thelounge.net wrote:
Am 15.02.2012 14:25, schrieb Miloslav Trmač:
I haven't seen this work and I don't think such snaphots can be relied
upon: /boot, /etc and /var are affected by installs as well
Miroslav -- you haven't seen this work
Martin Langhoff wrote:
Miroslav -- you haven't seen this work because the tasks are not all
yet in. But the stateless feature handles a lot of it already.
If you revert /usr to a snapshot without touching the rpmdb (in
/var/lib/rpm), your system will be in a very inconsistent state.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear developers,
Now that the /usrmove changes have landed in the F-17 branch, should
the ordering of directories in PATH be changed? /usr/bin should appear
before /bin and /usr/sbin before /sbin.
Right now $(which a-binary) would report that all
On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear developers,
Now that the /usrmove changes have landed in the F-17 branch, should
the ordering of directories in PATH be changed? /usr/bin should appear
before /bin and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/14/2012 05:11 PM, Ondrej Vasik wrote:
On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Dear developers,
Now that the /usrmove changes have landed in the F-17 branch,
should
On Tue, 2012-02-14 at 17:11 +0100, Ondrej Vasik wrote:
On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear developers,
Now that the /usrmove changes have landed in the F-17 branch, should
the ordering of directories
On Tue, 2012-02-14 at 17:33 +0100, Tomas Mraz wrote:
On Tue, 2012-02-14 at 17:11 +0100, Ondrej Vasik wrote:
On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear developers,
Now that the /usrmove changes have
- Original Message -
On Tue, 2012-02-14 at 17:11 +0100, Ondrej Vasik wrote:
On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear developers,
Now that the /usrmove changes have landed in the F-17 branch,
Ondrej Vasik wrote:
You are right, setup update fixed only /sbin locations... /bin has to be
done on glibc and shells side. Sorry for confusion...
WHY was UsrMove allowed to be merged in such broken and incomplete state?
Kevin Kofler
--
devel mailing list
On Tue, 14.02.12 23:08, Kevin Kofler (kevin.kof...@chello.at) wrote:
Ondrej Vasik wrote:
You are right, setup update fixed only /sbin locations... /bin has to be
done on glibc and shells side. Sorry for confusion...
WHY was UsrMove allowed to be merged in such broken and incomplete state?
Lennart Poettering wrote:
Because dropping these dirs from the search paths is merely an
optimization, not a requirement.
You call it an optimization, I call it fixing a pessimization (performance
regression).
And as the original message in the thread points out, the regression
actually
28 matches
Mail list logo
