Dan McGee wrote:
On Mon, Jul 20, 2009 at 5:28 PM, Aaron Griffin<[email protected]> wrote:
On Mon, Jul 20, 2009 at 5:24 PM, Dan McGee<[email protected]> wrote:
On Mon, Jul 20, 2009 at 5:12 PM, Aaron Griffin<[email protected]> wrote:
On Mon, Jul 20, 2009 at 4:33 PM, Dan McGee<[email protected]> wrote:
On Mon, Jul 20, 2009 at 3:38 PM, Steven Blatchford<[email protected]> wrote:
Hi Dan,
I'm sure this has been brought up in the pacman ML but I couldn't find
it quickly. Do you think it would be useful to check the architecture
of the machine (eg the output of 'uname -m') against the binary pacman
is downloading? Twice I've sync'd the file /etc/pacman.d/mirrorlist via
unison to my slicehost server from my i686 network. The latest bash4.0
upgrade hurt... like there were tears... and henceforth it's now known
in my house as "Grumpy Sunday".
I have no trouble creating a wrapper script, I just thought I'd toss it
out there.
Lastly, if you suggest I go the wrapper script method, besides trying to
parse the mirrorlist file, is there a nice way to get the architecture
of a file from pacman before it downloads it? /installs it?
Would you mind sending this to the pacman-dev ML or filing a bug
report instead next time? Unfortunately it will just get buried in my
personal email inbox. I'm copying the list on this response.
With that said, I think we could perhaps take some precautions for
such things, such as adding a pacman.conf option to verify the
architecture. Something such as:
RootDir = /
DBPath = /var/lib/pacman
Architecture = x86_64
Where the accepted options would be something like:
Architecture = { i686, x86_64, ppc, etc... } or "auto", which would
make a uname system call, check the machine[] field, and use that
instead of a value being hardcoded?
What does the rest of the list think? This wouldn't be too hard, and
of course a package coded with architecture "any" would get a free
pass.
Yeah, I definitely don't think using "uname -m" by default should be
done - what happens if I booted and i686 livecd to I could recover
something borked on my x86_64 machine? "Can't install package, wrong
arch" Grrr. Sure, you could use "linux64" in this case, but if you're
already chrooted to a live system that's nicely configured, this extra
step shouldn't be needed.
I don't think "auto" should be a setting though - I think it should
only be used if Architecture isn't found in pacman.conf and should
output a warning saying "Architecture not set in pacman.conf, using
<blah>"
I'm going to disagree with this- my default was going to be "don't
check" if left unset. However, I could go either way as long as both
"auto" and "nocheck" are somehow accommodated.
Ah, I wasn't actually thinking about the ability to circumvent the
check (why would you want to?) - could you explain when this would be
useful? Most cases where uname != (what you want) are probably in a
chroot and you have a pacman.conf there anyway.
1. Making something impossible is never good (this is mostly the
"unforeseen difficulties" excuse)
2. "probably" leaves a lot of wiggle room
3. If your name is Allan McRae (or anyone else) and you run an x86_64
kernel in an i686 userspace
4. If your name is <whoever> and you run random i686 package on a
mostly-x86_64 machine
Probably more, and some of these are weak, but there is enough of a
reason to allow it that I think it would be silly to lay down the law
for people that may need to circumvent the check.
And we all know #3 is the most important! :)
That said, I like this idea as long as it can be disabled. I have seen
people accidentally stuff there systems by doing this on many
occasions. Although, it does fall into the category of stopping stupid
people and we do have a -Rd option...
Allan
_______________________________________________
pacman-dev mailing list
[email protected]
http://www.archlinux.org/mailman/listinfo/pacman-dev
