#720 kay - provenpackager for /usr move
Closed None Opened 12 years ago by kay.

= phenomenon =
Please add me to the proven packager list.

= reason =
This would ease the process of the /usr move and allow us quick response/turnaround times for packaging fixes during the transition.

https://fedoraproject.org/wiki/Features/UsrMove

= recommendation =
We are responisble for the key boot components of the system, so the overall risk should not get much bigger. :)

Thanks in advance!


Would you mind telling us the concrete changes in packages that you're planning to do as provenpackager for the UsrMove feature? There were short discussion about helper script and also about changes in packages. But there was no definitive conclusion of what the concrete changes will be.

We need to change RPM itself to provide a guard (rpmlib()), so that converted packages can not be installed on older systems.

We need to bump the filesystem.rpm version and require the new RPM guard to o protect from getting installed on unconverted systems.

We need to convert ~30 packages which install conflicting files. These packages need to be rebuild. Example:
/bin/find
/usr/bin/find --> ../../bin/find
If the package in its current form is installed on a converted system with a link:
/bin --> /usr/bin
RPM might overwrite the actual binary with the packaged symlink. These packages will require the new filesystem.rpm.

We want to change ~200 packages to install things in /usr directly, so that the RPM lists are correct and not in compat mode. These packages do not need to be rebuild immediately, they can bring in that change with the next update.

The converted filesystem.rpm will directly create the compat symlinks /bin, /sbin, /lib, /lib64 when it is installed on a new system.

We provide a conversion script and anaconda preupgrade will be used to convert/update any installed system. After the conversion, RPM will provide the dependencies to be able to install the new filesystem.rpm, which will satisfy the dependencies for the converted packages.

Changing RPM is the first step, and we like to do that now. Step two is to make sure the RPM changes are available in the build system. The rest of the package converion will follow (next year) only after the anaconda changes landed in rawhide and are tested sufficiently.

Apart from anything else, the provenpackager status makes sense.

As for !UsrMove, the RPM thing is new... the upgrade path design seems to be still changing rather radically. Is there a current documentation anywhere? It's not in the feature page.

It's the result of talking with the rpm, anaconda, and yum maintainers. The big picture did not really change, only the way we plug in the convert script in got closer to a solution. We got the recommendation to primarily rely on yum preupgrade instead of using dracut to upgrade existing systems.

We will update the feature page when the current plan turn out to be working. I don't expect major changes, but the hookup of the migration script needs still to be finalized and tested.

Sent to sponsors list for feedback.

Not enough feedback... by policy, moving to meeting agenda.

This request was approved in the 2012-01-09 meeting.

I've added you to the group.

Use your powers for good!

Login to comment on this ticket.

Metadata