Bug 760996

Why is X-CheckUnifiedBindir there? I thought the merge of /usr/sbin and /usr/bin was abandoned?

It's just a simple flag for possible future use, it is not used today, but
we want it in RPM, to have this option.

 As the yum maintainer I would also ask that you not update F16 (and _esp_ F15) with this new rpm. With this patch, and the corresponding packaging changes "yum upgrade" won't do the transaction ... which is as good as it gets for upgrading to F17.

 We can prominently put release notes everywhere saying "you _have_ to use preupgrade/anaconda" for F17 upgrades due to usrmove. Having magic lists of instructions to pretend yum upgrade works is just asking for pain, I don't need. And for anyone who _really_ needs their fix, I'm sure someone will do special rpm builds on repos.fedorapeople.org or something.

(In reply to comment #3)
>  As the yum maintainer I would also ask that you not update F16 (and _esp_ F15)
> with this new rpm. With this patch, and the corresponding packaging changes
> "yum upgrade" won't do the transaction ... which is as good as it gets for
> upgrading to F17.
> 
>  We can prominently put release notes everywhere saying "you _have_ to use
> preupgrade/anaconda" for F17 upgrades due to usrmove. Having magic lists of
> instructions to pretend yum upgrade works is just asking for pain, I don't
> need. And for anyone who _really_ needs their fix, I'm sure someone will do
> special rpm builds on repos.fedorapeople.org or something.

So, you don't want the manual "dracut convert + manual yum update" to be possible?

 Not from default F16, no.

 Basically no matter what we do "yum upgrade" isn't going to "work", by any sane definition of how it's been used since Fedora 1 => Fedora 2. There is no plan to fix it so it will work, and have this feature. So I'd rather not pretend it can kind of work, if you just reboot 3 times and run random commands correctly.
 If we do that, then even if we say it's unsupported (as it "always" has been) I think users will correctly be filing 666 bugs against yum.

 Just tell everyone they _have_ to use preupgrade/anaconda and leave it at that.

(In reply to comment #5)
>  Not from default F16, no.
> 
>  Basically no matter what we do "yum upgrade" isn't going to "work", by any
> sane definition of how it's been used since Fedora 1 => Fedora 2. There is no
> plan to fix it so it will work, and have this feature. So I'd rather not
> pretend it can kind of work, if you just reboot 3 times and run random commands
> correctly.
>  If we do that, then even if we say it's unsupported (as it "always" has been)
> I think users will correctly be filing 666 bugs against yum.
> 
>  Just tell everyone they _have_ to use preupgrade/anaconda and leave it at
> that.

in this case only bug 760999 has to be accepted.

(In reply to comment #6)
> (In reply to comment #5)
> >  Not from default F16, no.
> > 
> >  Basically no matter what we do "yum upgrade" isn't going to "work", by any
> > sane definition of how it's been used since Fedora 1 => Fedora 2. There is no
> > plan to fix it so it will work, and have this feature. So I'd rather not
> > pretend it can kind of work, if you just reboot 3 times and run random commands
> > correctly.
> >  If we do that, then even if we say it's unsupported (as it "always" has been)
> > I think users will correctly be filing 666 bugs against yum.
> > 
> >  Just tell everyone they _have_ to use preupgrade/anaconda and leave it at
> > that.
> 
> in this case only bug 760999 has to be accepted.

oh and maybe the RHEL-6 version for the build servers bug 761000

rpm-4.9.1.2-4.fc16.1 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/rpm-4.9.1.2-4.fc16.1

Hmm, I was under the impression that we were not going add this to F15 and F16 to "force" use of preupgrade/anaconda. No big deal, just a little surprised to see these updates.

(In reply to comment #9)
> Hmm, I was under the impression that we were not going add this to F15 and F16
> to "force" use of preupgrade/anaconda.

That is right. We will still not suport live-udates without a reboot step
that converts the filesystem with dracut/anaconda, and prepares for the
installation of the converted packages.

The F15 F16 RPM patch is only to ease the suport for the build systems which
run on F15/F1. Secondary architectures need to run Fedora there. Release
Engineering asked us to do that.

Package rpm-4.9.1.2-4.fc16.1:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rpm-4.9.1.2-4.fc16.1'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-0912/rpm-4.9.1.2-4.fc16.1
then log in and leave karma (feedback).

rpm-4.9.1.2-4.fc16.1 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

test could be a test-convertfs.spec with:

Requires: rpmlib(X-CheckUnifiedSystemdir)

which would not install, unless the filesystem is converted.

And a test-unconvertfs.spec with:

Conflicts: rpmlib(X-CheckUnifiedSystemdir)

which should install fine on an unconverted filesystem (RHEL-6).