/usrmove? -> about the future

[Reindl Harald]

Am 10.02.2012 18:28, schrieb Jef Spaleta:
> On Fri, Feb 10, 2012 at 8:21 AM, Reindl Harald <h.reindl at thelounge.net> wrote:
>> F15 was the first Linux i saw where "reboot" did not
>> work until you typed "kill 1" while praying!
> 
> Can you point me to a bug report from you or anyone else that has been
> confirmed by at least one other person?
> 
> I personally didn't experience that with the F15 systems I had. But
> maybe I got lucked and dodged a bullet.

no i can not because it is a one-shot thing to do "yum distro-sync" and so i
had no time for a bugrport while other more important things like mysqld were
horrible broken

but this was reproduceable on all vritual machines a own including
my two physical machines and the notebook of my co-developer and shows
that something was not well thought or yum upgrades was never tested
enough because Fedora thinks Anaconda is the way too go what is
a horrible broken thing for a upgrade because you have no single
chance to verify grub-config, enabled services or anything and
blindly reboot in a unknown state if it boots

i made 3 fedora upgrades in my life with Anaconda/Preupgrade
and all 3 were horrible broken ending in a no longe rbotting
machine while around 200 dist-upgrades with yum were clean
and controllable - so any feature breaking yum upgrades while
services are UP is a spit in my face

and yes, if this braindead (sorry no other words) autorestart
of services while yum upgrade is running  would be controllable
instead spit it in each SPEC to force rebuild all these packages
would be optimized this whould make much more sense as move
files from here to there wich is not interesting any user and
was no problem for amny many years and is no problem currently
which needs to fixed under pressure

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120210/3eedb8c4/attachment.sig>