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. -Dan _______________________________________________ pacman-dev mailing list [email protected] http://www.archlinux.org/mailman/listinfo/pacman-dev
