10:08 a.m.
-----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 /usr/... binaries
are located in /bin and /sbin instead; while it is mostly just
cosmetic, some programs (e.g. pure-gen) use the heuristic of computing
their default installation prefix based on the location of another
binary, and get confused if that prefix is empty.
Is this a reasonable change? I'll file a bug report if that's the case.
Thanks,
- --
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPOocVAAoJEEr1VKujapN6ndoH/An7h4cw1Y0nUVttHIZ9dKiY
UAbpn5hkpCErWQhEfpP+Rxbcdn2x4yy2fVhSz8Q9KLP9cdolfyxNsV5eNojq3opt
6FZkClD/7Xz0UR1e5KpJye1+ogkiKEHLUheRgtJmH1ouXQ1heWTko4haYbmzmNl5
0qqpBDJVPBb4+rBhZxHMjwafbF3wkNt+gErb7rkJkOPzq7i5PpiXFkLSknhj8M/X
M4QijxIfnoN/WqyT+NkMfxUX/6KxFO+ZNnBDaXVQfBx3ywgLapbSmOHE/7sToiEZ
FO8/Qdu+7YtKHHqh26GHsOEBWUZfwXTMe4NOOlZCRRiV/rPCxLutX68x7M7VkP8=
=w41Y
-----END PGP SIGNATURE-----
10:11 a.m.
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 /usr/sbin before /sbin.
Right now $(which a-binary) would report that all /usr/... binaries
are located in /bin and /sbin instead; while it is mostly just
cosmetic, some programs (e.g. pure-gen) use the heuristic of computing
their default installation prefix based on the location of another
binary, and get confused if that prefix is empty.
Is this a reasonable change? I'll file a bug report if that's the case.
/bin and /sbin paths were already removed in latest setup package - as
you no longer need them... so no need for bugzilla and report...
Ondrej Vasik
10:28 a.m.
-----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 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 /usr/...
> binaries are located in /bin and /sbin instead; while it is
> mostly just cosmetic, some programs (e.g. pure-gen) use the
> heuristic of computing their default installation prefix based on
> the location of another binary, and get confused if that prefix
> is empty.
>
> Is this a reasonable change? I'll file a bug report if that's the
> case.
/bin and /sbin paths were already removed in latest setup package -
as you no longer need them... so no need for bugzilla and
report...
Ah, great. They are still used in Koji (even for Rawhide) but it's
probably just a matter of time then.
- --
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPOoufAAoJEEr1VKujapN60mgH/j5MaVuaqZKdqYuwyGA2/7tX
pl+KOJDBWdaAhFjz9MFNYlN5CtEVt+pGIEf0MuuDe9VKgNk+GNisThTI+9qtYVXz
MEjdl0FdGuPCIhPHnLGJwRqW4KPsByn2BVAzMJP+jCwSjYqwS3qN7/3LQPkZILaq
0MaApVxOUZYT2E1XpJqy7ad5fPj5TAorU9hn5+VJC+pgg8R0XNO5rU77CXMHI+MK
vwf7weHu3OOhlnqiXB4FH7DrtDla6hemlww78AuCE3tRCQ0QjaYjeoqpATBni9O6
qT6MvfTgR1LmvzD+j6rhpM+ndmjDhJ1AtFOku0zwFSDddtDft2AtMzOIxm2DxJ4=
=14en
-----END PGP SIGNATURE-----
10:33 a.m.
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 in PATH be changed? /usr/bin should appear
> before /bin and /usr/sbin before /sbin.
>
> Right now $(which a-binary) would report that all /usr/... binaries
> are located in /bin and /sbin instead; while it is mostly just
> cosmetic, some programs (e.g. pure-gen) use the heuristic of computing
> their default installation prefix based on the location of another
> binary, and get confused if that prefix is empty.
>
> Is this a reasonable change? I'll file a bug report if that's the case.
/bin and /sbin paths were already removed in latest setup package - as
you no longer need them... so no need for bugzilla and report...
I'm not sure, but I think bash has hardcoded PATH for /bin and /usr/bin
as well.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
11:23 a.m.
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 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 /usr/... binaries
> > are located in /bin and /sbin instead; while it is mostly just
> > cosmetic, some programs (e.g. pure-gen) use the heuristic of computing
> > their default installation prefix based on the location of another
> > binary, and get confused if that prefix is empty.
> >
> > Is this a reasonable change? I'll file a bug report if that's the
case.
>
> /bin and /sbin paths were already removed in latest setup package - as
> you no longer need them... so no need for bugzilla and report...
I'm not sure, but I think bash has hardcoded PATH for /bin and /usr/bin
as well.
Also, has the default linker path (in glibc, I guess?) been adjusted?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:28 a.m.
----- 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,
> > 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 /usr/...
> > binaries
> > are located in /bin and /sbin instead; while it is mostly just
> > cosmetic, some programs (e.g. pure-gen) use the heuristic of
> > computing
> > their default installation prefix based on the location of
> > another
> > binary, and get confused if that prefix is empty.
> >
> > Is this a reasonable change? I'll file a bug report if that's the
> > case.
>
> /bin and /sbin paths were already removed in latest setup package -
> as
> you no longer need them... so no need for bugzilla and report...
I'm not sure, but I think bash has hardcoded PATH for /bin and
/usr/bin
as well.
You are right, setup update fixed only /sbin locations... /bin has to be done
on glibc and shells side. Sorry for confusion...
Greetings,
Ondrej Vasik
4:13 p.m.
On Tue, 14.02.12 23:08, Kevin Kofler (kevin.kofler(a)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?
Because dropping these dirs from the search paths is merely an
optimization, not a requirement.
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:26 p.m.
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 affects more than just performance, it also causes genuine bugs
(with automatic prefix detection in applications).
Kevin Kofler
3:37 a.m.
On Wed, Feb 15, 2012 at 1:26 AM, Kevin Kofler <kevin.kofler(a)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 as the original message in the thread points out, the regression
actually affects more than just performance, it also causes genuine bugs
(with automatic prefix detection in applications).
So? Should we drop all features that aren't bug free after feature freeze?
You complain as if we are going to release GA tomorrow.
4:18 a.m.
On 02/15/2012 10:37 AM, drago01 wrote:
On Wed, Feb 15, 2012 at 1:26 AM, Kevin
Kofler<kevin.kofler(a)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 as the original message in the thread points out, the regression
> actually affects more than just performance, it also causes genuine bugs
> (with automatic prefix detection in applications).
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 works.
Better stop this non-sense now!
4:25 a.m.
On Wed, Feb 15, 2012 at 11:18 AM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
On 02/15/2012 10:37 AM, drago01 wrote:
>
> On Wed, Feb 15, 2012 at 1:26 AM, Kevin Kofler<kevin.kofler(a)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 as the original message in the thread points out, the regression
>> actually affects more than just performance, it also causes genuine bugs
>> (with automatic prefix detection in applications).
>
>
> 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 this?
We are at pre alpha / alpha ... users should not have to care about
that right now.
It communicates a nice
impression of the quality of your works.
I am not involved in this so it is not "my works" ...
Better stop this non-sense now!
The only nonsense I see here is people ranting for the sake of ranting.
4:33 a.m.
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 this?
We are at pre alpha / alpha ... users should not have to care about
that right now.
> It communicates a nice
> impression of the quality of your works.
I am not involved in this so it is not "my works" ...
> Better stop this non-sense now!
The only nonsense I see here is people ranting for the sake of ranting.
people are ranting because the experience how buggy are
features in the GA-releases if they are in such a not
conesquently thought state at alpha
the last releases it was always fact that they was not ready until
GA and if they can't be fixed then "common bugs" are listed in
the release notes
the problem is here that first the work/change/feature is started as
happend often in the past and in the middle of the work more
and more people coming with things nobody cared in tghe planning
phase what let many of us feel like "there is nothing planned, there
were people starting and forcing without any thoughts and the hope
that all will get sorted until GA"
5:05 a.m.
Am 15.02.2012 11:20 schrieb "Ralf Corsepius" <rc040203(a)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... "nothing else is broken and my PATH is non-optimal, stop the
usrmove, because I don't want it."
this is so ridicoulus...
5:16 a.m.
Am 15.02.2012 12:05, schrieb Harald Hoyer:
Am 15.02.2012 11:20 schrieb "Ralf Corsepius"
<rc040203(a)freenet.de <mailto:rc040203@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... "nothing else is broken and my PATH is non-optimal, stop the usrmove,
because I don't want it."
the "nothing else" we will see later
fact is that the "feauture" is included and now people are
coming "did we think about this and this and this..."
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
this feels like you guys has no other things to do and sitting
there "hmm let us search for solutions press into a release and
let us search for constructed problems the solution may solve
to have any valid reason to do it now"
5:24 a.m.
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.
Here, your point is invalid.
Harald, you are generating copius amounts of stop-energy. You really
should participate in Fedora process as it designed - during feature
proposals, discussions, implementation. Right now you are ranting post factum.
The amount of time you waste on this mail list is huge, and it is a sad
waste. It would be better spent on filling bugs on real issues.
Because bugs, you know, get fixed. I even remember one bug that you have
filled about some deamon not shipping a systemd unit. I saw this bug,
I've created and attached unit file, it got shipped by maintainer. Case closed.
This is the best way of participation.
Your baseless, repetitive rants finally made me blacklist you. It's very
sad for me, as I believe in open participation and meritocracy.
Good bye,
--
Tomasz Torcz To co nierealne -- tutaj jest normalne.
xmpp: zdzichubg(a)chrome.pl Ziomale na życie mają tu patenty specjalne.
5:50 a.m.
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, because I have a strong need for clean system.
Here, your point is invalid.
you mean all existing linux-installations are unclean?
you need a clean system but accept that half of the distribution
is a mix of systemd/sysv/lsb - you would get a clean system if
the work of one feature would be COMPLETLY done before the next
is started, but seems that most people have no intention nor
the make nor any idea what is a clean system
6:43 a.m.
On Feb 15, 2012 6:16 AM, "Reindl Harald" <h.reindl(a)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 to
snapshot your OS install partition. Add btrfs, yum hooks and the
already-implemented "stateless" configuration and you have a really major
feature: a fully upgrade/test/rollback setup for Fedora.
For OLPC for example, this could be a major win, hence my interest. I
definitely want it for my laptop. I'm sure many running rawhide will want
it :-) -- upgrade/test/file bugs if it breaks/rollback if it's real bad.
cheers,
m
{ Martin Langhoff - one laptop per child }
6:53 a.m.
Am 15.02.2012 13:43, schrieb Martin Langhoff:
On Feb 15, 2012 6:16 AM, "Reindl Harald"
<h.reindl(a)thelounge.net <mailto:h.reindl@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 to snapshot your OS
install partition. Add
btrfs, yum hooks and the already-implemented "stateless" configuration and you
have a really major feature: a fully
upgrade/test/rollback setup for Fedora.
only one out of a million installations have /usr seperated
from / and the default is NOT do this - so no there is no
impact on any normal setup
6:22 a.m.
Reindl Harald wrote:
Am 15.02.2012 13:43, schrieb Martin Langhoff:
> On Feb 15, 2012 6:16 AM, "Reindl Harald" <h.reindl(a)thelounge.net
> <mailto:h.reindl@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
> to snapshot your OS install partition. Add
> btrfs, yum hooks and the already-implemented "stateless"
> configuration and you have a really major feature: a fully
> upgrade/test/rollback setup for Fedora.
only one out of a million installations have /usr seperated
from / and the default is NOT do this - so no there is no
impact on any normal setup
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 ext4 10G 7.3G 2.3G 77% /usr
I know I'm special ;-), but *that* special? I doubt it.
6:27 a.m.
Am 16.02.2012 13:22, schrieb Jim Meyering:
Reindl Harald wrote:
> Am 15.02.2012 13:43, schrieb Martin Langhoff:
>> On Feb 15, 2012 6:16 AM, "Reindl Harald" <h.reindl(a)thelounge.net
>> <mailto:h.reindl@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
>> to snapshot your OS install partition. Add
>> btrfs, yum hooks and the already-implemented "stateless"
>> configuration and you have a really major feature: a fully
>> upgrade/test/rollback setup for Fedora.
>
> only one out of a million installations have /usr seperated
> from / and the default is NOT do this - so no there is no
> impact on any normal setup
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 ext4 10G 7.3G 2.3G 77% /usr
I know I'm special ;-), but *that* special? I doubt it
with what benefit?
as said: it is and will be useless bomb the OS after a upgrade back
to a filesystem snapshot of /usr since the RPM-DATABASE will NOT
be restored, configurations in /etc will NOT be restored
so can anybody give me one single benefit of /usrmove?
sorry, regardless how often i read any article to this
topic all this benefits are theoretical and will not
work in the real life or not change anything for a user
8:02 a.m.
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.reindl(a)thelounge.net
>> <mailto:h.reindl@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
>> to snapshot your OS install partition. Add
>> btrfs, yum hooks and the already-implemented "stateless"
>> configuration and you have a really major feature: a fully
>> upgrade/test/rollback setup for Fedora.
>
> only one out of a million installations have /usr seperated
> from / and the default is NOT do this - so no there is no
> impact on any normal setup
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 ext4 10G 7.3G 2.3G 77% /usr
I know I'm special ;-), but *that* special? I doubt it.
I guess it is time to change habits, what's the point of a separate /usr
these days ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10:55 a.m.
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 ext4 10G 7.3G 2.3G 77% /usr
>
> I know I'm special ;-), but *that* special? I doubt it.
I guess it is time to change habits, what's the point of a separate /usr
these days ?
I like to keep "/" very small, separate and mostly read-only, so that
when something goes wrong with the disk it's less likely to affect
the root partition, so I'm all for the implicit writable/read-only
segregation this implies.
/usrmove is a clear win.
11:09 a.m.
>>>> "SS" == Simo Sorce <simo(a)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 it). For me it was simply keeping / small and
being able to back it up easily without backing up all of the stuff in
/usr.
- J<
7:25 a.m.
On Wed, Feb 15, 2012 at 1:43 PM, Martin Langhoff
<martin.langhoff(a)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
feature: a fully upgrade/test/rollback setup for Fedora.
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
(especially in the cases where you would want to roll back); I don't
think anybody wants exactly the separation provided by the crude /usr
vs. rest that is provided by the /usr move.
And snapshots that can not be relied upon may be even worse than no
snapshots if they motivate users to skip creating proper backups.
Mirek
7:30 a.m.
Am 15.02.2012 14:25, schrieb Miloslav Trmač:
On Wed, Feb 15, 2012 at 1:43 PM, Martin Langhoff
<martin.langhoff(a)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
> feature: a fully upgrade/test/rollback setup for Fedora.
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
(especially in the cases where you would want to roll back); I don't
think anybody wants exactly the separation provided by the crude /usr
vs. rest that is provided by the /usr move.
this is a additional reason why the /usrmove is completly
useless because it suggests users they are save using any
FS-snapshot
have many fun after a big upgrade to revert the snapshot
if you really have /usr on a seperated FS and your
/etc and /var/lib/rpm will stay in the state after the
upgrade and your FS is bombed back
so for users having a default setup there is no difference
because / as /etc and /usr is the same FS and for ones
have seperated /usr it does not bring any benefit in real life
with other words: the whole work which is done here is useless
and low brained with constrcuted arguments not working in
the real life and they were only coonstructed to push this
feature because some developers are bored and fear this
maybe happen also to users if they do not change permanently
things which are working fine
yes i know, now i get a reply about "politness" -> but face the truth!
11:12 a.m.
On Wed, Feb 15, 2012 at 8:30 AM, Reindl Harald <h.reindl(a)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 because the tasks are not all
yet in. But the "stateless" feature handles a lot of it already.
this is a additional reason why the /usrmove is completly
Harald, it is one step in a process. I am very happy and thankful that
Fedora is working in this direction.
Now, it's time for me to step aside from this thread.
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
4:52 p.m.
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.
Kevin Kofler
5:10 a.m.
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 works.
Better stop this non-sense now!
I'm a user, don't have a problem.
--
Regards
FRank
4463
days inactive
4465
days old
28 comments
17 participants
participants (17)
-
Adam Williamson -
drago01 -
Frank Murphy -
Harald Hoyer -
Jason L Tibbitts III -
Jim Meyering -
Kevin Kofler -
Lennart Poettering -
Martin Langhoff -
Michel Alexandre Salim -
Miloslav Trmač -
Ondřej Vašík -
Ralf Corsepius -
Reindl Harald -
Simo Sorce -
Tomas Mraz -
Tomasz Torcz