[arch-dev-public] [signoff] pacman 3.4.0-2
On Wed, Jun 16, 2010 at 9:42 PM, Allan McRae <allan@archlinux.org> wrote:
On 17/06/10 12:34, Dan McGee wrote:
Upstream release, please signoff.
Please make sure to update your makepkg.conf when updating to this, _including in your chroots_. There may be file stripping issues if you do not...
And a summary of the upstream changes: http://projects.archlinux.org/pacman.git/tree/NEWS?id=v3.4.0
OK, new -2 release in testing with the following changes, I'd like signoffs for real this time around: * We now have manpages * Fix optdepends * Patch the above mentioned strip libraries issue with patch from git so it is not disastrous There is also a new pacman-mirrorlist package in testing with the following change: * Move to multi-arch and use $arch variable in the list Please ensure it works with the new pacman; it will not be moving before it. -Dan
On Mon, Jun 21, 2010 at 15:57, Dan McGee <dpmcgee@gmail.com> wrote:
On Wed, Jun 16, 2010 at 9:42 PM, Allan McRae <allan@archlinux.org> wrote:
On 17/06/10 12:34, Dan McGee wrote:
Upstream release, please signoff.
Please make sure to update your makepkg.conf when updating to this, _including in your chroots_. There may be file stripping issues if you do not...
And a summary of the upstream changes: http://projects.archlinux.org/pacman.git/tree/NEWS?id=v3.4.0
OK, new -2 release in testing with the following changes, I'd like signoffs for real this time around: * We now have manpages * Fix optdepends * Patch the above mentioned strip libraries issue with patch from git so it is not disastrous
There is also a new pacman-mirrorlist package in testing with the following change: * Move to multi-arch and use $arch variable in the list
Please ensure it works with the new pacman; it will not be moving before it.
signoff pacman x86_64 and pacman-mirrorlist -- Roman Kyrylych (Роман Кирилич)
On 22/06/10 03:37, Roman Kyrylych wrote:
On Mon, Jun 21, 2010 at 15:57, Dan McGee<dpmcgee@gmail.com> wrote:
On Wed, Jun 16, 2010 at 9:42 PM, Allan McRae<allan@archlinux.org> wrote:
On 17/06/10 12:34, Dan McGee wrote:
Upstream release, please signoff.
Please make sure to update your makepkg.conf when updating to this, _including in your chroots_. There may be file stripping issues if you do not...
And a summary of the upstream changes: http://projects.archlinux.org/pacman.git/tree/NEWS?id=v3.4.0
OK, new -2 release in testing with the following changes, I'd like signoffs for real this time around: * We now have manpages * Fix optdepends * Patch the above mentioned strip libraries issue with patch from git so it is not disastrous
There is also a new pacman-mirrorlist package in testing with the following change: * Move to multi-arch and use $arch variable in the list
Please ensure it works with the new pacman; it will not be moving before it.
signoff pacman x86_64 and pacman-mirrorlist
Signoff both on both. Allan
Am 21.06.2010 14:57, schrieb Dan McGee:
OK, new -2 release in testing with the following changes, I'd like signoffs for real this time around: * We now have manpages * Fix optdepends * Patch the above mentioned strip libraries issue with patch from git so it is not disastrous
There is also a new pacman-mirrorlist package in testing with the following change: * Move to multi-arch and use $arch variable in the list
Please ensure it works with the new pacman; it will not be moving before it.
-Dan
Big Bad Signoff for it all. One thing I noticed though: If the Architecture option is missing in pacman.conf, pacman will not recognize the $arch substitution. Wouldn't it be more intuitive to have 'Architecture = auto' as the default and use 'Architecture = none' to disable the feature?
On Tue, Jun 22, 2010 at 7:54 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 21.06.2010 14:57, schrieb Dan McGee:
OK, new -2 release in testing with the following changes, I'd like signoffs for real this time around: * We now have manpages * Fix optdepends * Patch the above mentioned strip libraries issue with patch from git so it is not disastrous
There is also a new pacman-mirrorlist package in testing with the following change: * Move to multi-arch and use $arch variable in the list
Please ensure it works with the new pacman; it will not be moving before it.
-Dan
Big Bad Signoff for it all.
One thing I noticed though: If the Architecture option is missing in pacman.conf, pacman will not recognize the $arch substitution.
Wouldn't it be more intuitive to have 'Architecture = auto' as the default and use 'Architecture = none' to disable the feature?
The manpage explains our reasoning why pretty clearly. Architecture = auto | i686 | x86_64 | ... If set, pacman will only allow installation of packages of the given architecture (e.g. i686, x86_64, etc). The special value auto will use the system architecture, provided by in “uname -m”. If unset, no architecture checks are made. NOTE: packages with the special architecture any can always be installed, as they are meant to be architecture independent. -Dan
Am 22.06.2010 15:03, schrieb Dan McGee:
Wouldn't it be more intuitive to have 'Architecture = auto' as the default and use 'Architecture = none' to disable the feature?
The manpage explains our reasoning why pretty clearly.
Architecture = auto | i686 | x86_64 | ... If set, pacman will only allow installation of packages of the given architecture (e.g. i686, x86_64, etc). The special value auto will use the system architecture, provided by in “uname -m”. If unset, no architecture checks are made. NOTE: packages with the special architecture any can always be installed, as they are meant to be architecture independent.
This doesn't explain anything, this just re-states what I wrote above. I am trying to understand why the option isn't: Architecture = none | auto | i686 | x86_64 | ... where 'auto' is the default instead of 'none'.
On 22/06/10 23:15, Thomas Bächler wrote:
Am 22.06.2010 15:03, schrieb Dan McGee:
Wouldn't it be more intuitive to have 'Architecture = auto' as the default and use 'Architecture = none' to disable the feature?
The manpage explains our reasoning why pretty clearly.
Architecture = auto | i686 | x86_64 | ... If set, pacman will only allow installation of packages of the given architecture (e.g. i686, x86_64, etc). The special value auto will use the system architecture, provided by in “uname -m”. If unset, no architecture checks are made. NOTE: packages with the special architecture any can always be installed, as they are meant to be architecture independent.
This doesn't explain anything, this just re-states what I wrote above. I am trying to understand why the option isn't: Architecture = none | auto | i686 | x86_64 | ... where 'auto' is the default instead of 'none'.
"Architecture = auto" causes issues on any system where the kernel is not built for the same architecture as the packages (waves hand as someone who cannot use it...). "Architecture = none" causes no restrictions on the system setup so is the default. Allan
Am 22.06.2010 15:31, schrieb Allan McRae:
"Architecture = auto" causes issues on any system where the kernel is not built for the same architecture as the packages (waves hand as someone who cannot use it...). "Architecture = none" causes no restrictions on the system setup so is the default.
'Architecture = auto' is the common case, so it should be the default (and actually, the default configuration file contains it). 'Architecture = none' is a rare corner case that virtually nobody will need, so it should not be the default. Just my 2 cents on sane default values.
On Tue, 22 Jun 2010 17:21:32 +0200, Thomas Bächler <thomas@archlinux.org> wrote:
Am 22.06.2010 15:31, schrieb Allan McRae:
"Architecture = auto" causes issues on any system where the kernel is not built for the same architecture as the packages (waves hand as someone who cannot use it...). "Architecture = none" causes no restrictions on the system setup so is the default.
'Architecture = auto' is the common case, so it should be the default (and actually, the default configuration file contains it). 'Architecture = none' is a rare corner case that virtually nobody will need, so it should not be the default. Just my 2 cents on sane default values.
I agree with Thomas here; the common case should be the default; not the rare corner case. At least on Arch you don't have mixed architectures anyway. -- Pierre Schmitz, https://users.archlinux.de/~pierre
participants (5)
-
Allan McRae
-
Dan McGee
-
Pierre Schmitz
-
Roman Kyrylych
-
Thomas Bächler