On 5/11/07, Paul Mattal <paul@mattal.com> wrote:
Since pacman 3, makepkg builds:
foo-2.9-1-i686.pkg.tar.gz
instead of the old
foo-2.9-1.pkg.tar.gz
What is our migration path for using that in all the repos? More specifically:
Thought we got some word out on this, but I'll try to state what we were planning on doing.
* How do we tell pacman to start using the new syntax when looking for packages? Do we need to, or do the repo db files take care of that?
Pacman 3.0 is fully compatible with the old or new names. The DBs now contain a %FILENAME% field that tells pacman where the package is located. However, pacman 2.X will fail on anything other than the old standard name. This means that for some period of time (feedback would be nice on this), we need to keep packages with the old naming scheme so pacman 2.X users can still use our sync DBs. At some point we can stop the renaming of packages.
* How do we synchronize the update of devtools and aurtools?
I personally use a bash function to rename my built packages stripping the arch name from them. I'll paste it at the bottom. Another thought is to modify the line in makepkg that names the package, but that is a bit hackish.
* How do we control/manage the propagating all that via mirrors, since all the filenames will change and each mirror will essentially want to do a full re-download?
Old files are not affected- we don't need to do anything to them.
* Do we announce some time for a flashover and tell devs not to update packages during that time?
We shouldn't have to have any holding period, as both names are fine in the eyes of pacman 3.0. However, we will need to decide a time when we will stop renaming the packages to names without the -ARCH extension.
Maybe someone's already figure this all out, but it would be nice to know how this is going to be handled so we can decide what to do to plan ahead.
Sorry if the ball got dropped here. By the way, the reasoning behind adding the -ARCH to the packages is simple- it prevents (slows down?) users from installing a package they shouldn't on their architecture. Before, you could not tell without unzipping the package which architecture it was built for- this allows us to be completely sure. In addition, it opens up things before that weren't possible, such as having packages for two architectures in the same directory (I'm not suggesting this, just saying it is now possible). Here is that bash function (it isn't idempotent, only run it once): makeoldname() { mv $1 "${1%-*.pkg.tar.gz}.pkg.tar.gz" } -Dan