[arch-dev-public] Finishing the /usr move
I'm bored of waiting... so lets do this! What a plans with regard to [staging] in the near future? When it is free, I will kill the current TODO list and create a new one.
As far as building goes, I'd suggest building in a [testing] chroot and then uploading to [staging]. Building from [staging] is likely to be completely broken during this transition.
Draft upgrade instructions:
1) Fix any non-official packages with files in /bin, /sbin or /usr/sbin to put those files in /usr/bin. The list of packages to be fixed can be generated using: $ comm -12 <(pacman -Qqm) <(pacman -Qqo /bin /sbin /usr/sbin | sort -u)
2) Make sure any packages in IgnorePkg or IgnoreGroup do not have files in /bin, /sbin, or /usr/sbin. Fix them if necessary.
3) Update your system: $ pacman -Syu --ignore filesystem $ pacman -Su
And that should be enough... With pacman-4.1 (and the patched 4.0.x versions in our repos since the /lib move), anybody just doing a "pacman -Syu" will get a conflict. Using --force in pamcan-4.1 will not break things (I think...) as --force does not allow overwriting a directory with a file. People using pacman-4.0.x and --force could still break their system.
Allan
[2013-05-29 11:56:57 +1000] Allan McRae:
- Fix any non-official packages with files in /bin, /sbin or /usr/sbin
to put those files in /usr/bin.
How should we handle paths that are hardcoded everywhere, such as /usr/sbin/sendmail? Will the filesystem package ship a global symlink from /usr/sbin to /usr/bin?
On 29/05/13 17:57, Gaetan Bisson wrote:
[2013-05-29 11:56:57 +1000] Allan McRae:
- Fix any non-official packages with files in /bin, /sbin or /usr/sbin
to put those files in /usr/bin.
How should we handle paths that are hardcoded everywhere, such as /usr/sbin/sendmail? Will the filesystem package ship a global symlink from /usr/sbin to /usr/bin?
Yes - /sbin, /usr/sbin and /bin will all point at /usr/bin. So hardcoded paths will not matter. Only file locations will.
Allan
On Wed, May 29, 2013 at 3:56 AM, Allan McRae allan@archlinux.org wrote:
I'm bored of waiting... so lets do this!
Please do. I suppose people can still skip staging for packages where that makes sense to minimize the congestion?
What a plans with regard to [staging] in the near future?
If you don't do this soon-ish I was going to do some bluez stuff, but I'm happy to wait if this moves forward.
-t
On Tue, May 28, 2013 at 9:56 PM, Allan McRae allan@archlinux.org wrote:
I'm bored of waiting... so lets do this! What a plans with regard to [staging] in the near future? When it is free, I will kill the current TODO list and create a new one.
I just moved the openobex rebuild to the testing repo. The staging repos are currently empty.
As far as building goes, I'd suggest building in a [testing] chroot and then uploading to [staging]. Building from [staging] is likely to be completely broken during this transition.
Looks like a good plan.
Eric
Draft upgrade instructions:
- Fix any non-official packages with files in /bin, /sbin or /usr/sbin
to put those files in /usr/bin. The list of packages to be fixed can be generated using: $ comm -12 <(pacman -Qqm) <(pacman -Qqo /bin /sbin /usr/sbin | sort -u)
- Make sure any packages in IgnorePkg or IgnoreGroup do not have files
in /bin, /sbin, or /usr/sbin. Fix them if necessary.
- Update your system:
$ pacman -Syu --ignore filesystem $ pacman -Su
And that should be enough... With pacman-4.1 (and the patched 4.0.x versions in our repos since the /lib move), anybody just doing a "pacman -Syu" will get a conflict. Using --force in pamcan-4.1 will not break things (I think...) as --force does not allow overwriting a directory with a file. People using pacman-4.0.x and --force could still break their system.
Allan
On 30/05/13 06:23, Eric Bélanger wrote:
On Tue, May 28, 2013 at 9:56 PM, Allan McRae allan@archlinux.org wrote:
I'm bored of waiting... so lets do this! What a plans with regard to [staging] in the near future? When it is free, I will kill the current TODO list and create a new one.
I just moved the openobex rebuild to the testing repo. The staging repos are currently empty.
Good. Rebuild has started.
I may have possible added to many packages to the TODO list initially, so people will have received emails about packages that are already done.
Allan
On Thu, May 30, 2013 at 5:35 AM, Allan McRae allan@archlinux.org wrote:
On 30/05/13 06:23, Eric Bélanger wrote:
On Tue, May 28, 2013 at 9:56 PM, Allan McRae allan@archlinux.org wrote:
I'm bored of waiting... so lets do this! What a plans with regard to [staging] in the near future? When it is free, I will kill the current TODO list and create a new one.
I just moved the openobex rebuild to the testing repo. The staging repos are currently empty.
Good. Rebuild has started.
I may have possible added to many packages to the TODO list initially, so people will have received emails about packages that are already done.
Thanks Allan.
The rebuild is now well under way and, even thought not all of [core] is done yet, it should already be possible to upgrade a very minimal system to [staging] (in case anyone wants to test that things are working as they should).
-t
On Thu, May 30, 2013 at 4:31 PM, Tom Gundersen teg@jklm.no wrote:
On Thu, May 30, 2013 at 5:35 AM, Allan McRae allan@archlinux.org wrote:
On 30/05/13 06:23, Eric Bélanger wrote:
On Tue, May 28, 2013 at 9:56 PM, Allan McRae allan@archlinux.org wrote:
I'm bored of waiting... so lets do this! What a plans with regard to [staging] in the near future? When it is free, I will kill the current TODO list and create a new one.
I just moved the openobex rebuild to the testing repo. The staging repos are currently empty.
Good. Rebuild has started.
Nice.
The rebuild is now well under way and, even thought not all of [core] is done yet, it should already be possible to upgrade a very minimal system to [staging] (in case anyone wants to test that things are working as they should).
I've rebuilt remaining packages in community. Reviews are welcome.
If we release an official kernel during the merge, the package ndiswrapper in cty-staging needs attention.
Cheers,
-- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
On 29/05/13 11:56, Allan McRae wrote:
Draft upgrade instructions:
- Fix any non-official packages with files in /bin, /sbin or /usr/sbin
to put those files in /usr/bin. The list of packages to be fixed can be generated using: $ comm -12 <(pacman -Qqm) <(pacman -Qqo /bin /sbin /usr/sbin | sort -u)
- Make sure any packages in IgnorePkg or IgnoreGroup do not have files
in /bin, /sbin, or /usr/sbin. Fix them if necessary.
- Update your system:
$ pacman -Syu --ignore filesystem $ pacman -Su
I just upgraded to the [staging] repo because packages I use are rebuilt...
Doing a "pacman -Syu" gave a conflict as expected. Did not test that "pacman -Syu --force" failed, because it was on my only working system at the moment.
The followed the instructions above. Rebooted at the end for good measure. DONE! No issues.
Allan
On Fri, May 31, 2013 at 5:50 AM, Allan McRae allan@archlinux.org wrote:
Doing a "pacman -Syu" gave a conflict as expected. Did not test that "pacman -Syu --force" failed, because it was on my only working system at the moment.
The followed the instructions above. Rebooted at the end for good measure. DONE! No issues.
I did the same yesterday, no issues for me either. Also checked that in case a package with files in /sbin (or so) is left we get the expected conflict.
-t
And it is now in the [testing] repository.
A reminder of the upgrade instructions:
1) Fix any non-official packages with files in /bin, /sbin or /usr/sbin to put those files in /usr/bin. The list of packages to be fixed can be generated using: $ comm -12 <(pacman -Qqm) <(pacman -Qqo /bin /sbin /usr/sbin | sort -u)
2) Make sure any packages in IgnorePkg or IgnoreGroup do not have files in /bin, /sbin, or /usr/sbin. Fix them if necessary.
3) Update your system: $ pacman -Syu --ignore filesystem $ pacman -Su
Do not use --force. pacman-4.1 will not let you anyway...
Allan
On Fri, May 31, 2013 at 12:02 PM, Allan McRae allan@archlinux.org wrote:
And it is now in the [testing] repository.
A reminder of the upgrade instructions:
- Fix any non-official packages with files in /bin, /sbin or /usr/sbin
to put those files in /usr/bin. The list of packages to be fixed can be generated using: $ comm -12 <(pacman -Qqm) <(pacman -Qqo /bin /sbin /usr/sbin | sort -u)
A sort is needed for the first pacman call.
$ comm -12 <(pacman -Qqm) <(pacman -Qqo /bin /sbin /usr/sbin | sort -u) ... comm: file 1 is not in sorted order
Cheers,
On 31/05/13 21:03, Sébastien Luttringer wrote:
On Fri, May 31, 2013 at 12:02 PM, Allan McRae allan@archlinux.org wrote:
And it is now in the [testing] repository.
A reminder of the upgrade instructions:
- Fix any non-official packages with files in /bin, /sbin or /usr/sbin
to put those files in /usr/bin. The list of packages to be fixed can be generated using: $ comm -12 <(pacman -Qqm) <(pacman -Qqo /bin /sbin /usr/sbin | sort -u)
A sort is needed for the first pacman call.
$ comm -12 <(pacman -Qqm) <(pacman -Qqo /bin /sbin /usr/sbin | sort -u) ... comm: file 1 is not in sorted order
Cheers,
Hrm... I was sure pacman sorted this occording to the system locale. Will add for the news post.
Allan
On Fri, May 31, 2013 at 1:27 PM, Allan McRae allan@archlinux.org wrote:
On 31/05/13 21:03, Sébastien Luttringer wrote:
On Fri, May 31, 2013 at 12:02 PM, Allan McRae allan@archlinux.org wrote:
And it is now in the [testing] repository.
A reminder of the upgrade instructions:
- Fix any non-official packages with files in /bin, /sbin or /usr/sbin
to put those files in /usr/bin. The list of packages to be fixed can be generated using: $ comm -12 <(pacman -Qqm) <(pacman -Qqo /bin /sbin /usr/sbin | sort -u)
A sort is needed for the first pacman call.
$ comm -12 <(pacman -Qqm) <(pacman -Qqo /bin /sbin /usr/sbin | sort -u) ... comm: file 1 is not in sorted order
Cheers,
Hrm... I was sure pacman sorted this occording to the system locale. Will add for the news post.
Allan
Another small suggestion about the message, it doesn't detect packages in unofficial repositories. I had some packages conflicting and not detected because they are in my personal repostory. I used the following command to detect all packages (except filesystem).
comm -12 <(pacman -Qq|grep -v filesystem|sort) <(pacman -Qqo /bin /sbin /usr/sbin|sort)
Why not symlink /usr/local/sbin to /usr/local/bin in filesystems?
Cheers,
-- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
On Fri, May 31, 2013 at 1:35 PM, Sébastien Luttringer seblu@seblu.net wrote:
Why not symlink /usr/local/sbin to /usr/local/bin in filesystems?
I think we should do this, but not everyone agrees. As it is independent of the current move, let's discuss it once that has finished.
-t
On 31/05/13 21:35, Sébastien Luttringer wrote:
On Fri, May 31, 2013 at 1:27 PM, Allan McRae allan@archlinux.org wrote:
On 31/05/13 21:03, Sébastien Luttringer wrote:
On Fri, May 31, 2013 at 12:02 PM, Allan McRae allan@archlinux.org wrote:
And it is now in the [testing] repository.
A reminder of the upgrade instructions:
- Fix any non-official packages with files in /bin, /sbin or /usr/sbin
to put those files in /usr/bin. The list of packages to be fixed can be generated using: $ comm -12 <(pacman -Qqm) <(pacman -Qqo /bin /sbin /usr/sbin | sort -u)
A sort is needed for the first pacman call.
$ comm -12 <(pacman -Qqm) <(pacman -Qqo /bin /sbin /usr/sbin | sort -u) ... comm: file 1 is not in sorted order
Cheers,
Hrm... I was sure pacman sorted this occording to the system locale. Will add for the news post.
Allan
Another small suggestion about the message, it doesn't detect packages in unofficial repositories. I had some packages conflicting and not detected because they are in my personal repostory. I used the following command to detect all packages (except filesystem).
comm -12 <(pacman -Qq|grep -v filesystem|sort) <(pacman -Qqo /bin /sbin /usr/sbin|sort)
And then had to go through the list and check what was in the repos...
I'll add a note to check unofficial repo packages.
Why not symlink /usr/local/sbin to /usr/local/bin in filesystems?
Because there is absolutely no upgrade path for that.
Am 31.05.2013 13:40, schrieb Allan McRae:
Why not symlink /usr/local/sbin to /usr/local/bin in filesystems?
Because there is absolutely no upgrade path for that.
Wouldn't this work?
$ pacman -Syu --ignore filesystem $ mv -i /usr/local/sbin/* /usr/local/bin $ pacman -Syu
On 31/05/13 21:44, Pierre Schmitz wrote:
Am 31.05.2013 13:40, schrieb Allan McRae:
Why not symlink /usr/local/sbin to /usr/local/bin in filesystems?
Because there is absolutely no upgrade path for that.
Wouldn't this work?
$ pacman -Syu --ignore filesystem $ mv -i /usr/local/sbin/* /usr/local/bin $ pacman -Syu
Conflicts, packages installed there with a package manager, ... People do dumb things with /usr/local.
participants (6)
-
Allan McRae
-
Eric Bélanger
-
Gaetan Bisson
-
Pierre Schmitz
-
Sébastien Luttringer
-
Tom Gundersen