[pacman-dev] architecture warn/check

[Allan McRae]

Dan McGee wrote:
> On Mon, Jul 20, 2009 at 5:28 PM, Aaron Griffin<aaronmgriffin at gmail.com> wrote:
>   
>> On Mon, Jul 20, 2009 at 5:24 PM, Dan McGee<dpmcgee at gmail.com> wrote:
>>     
>>> On Mon, Jul 20, 2009 at 5:12 PM, Aaron Griffin<aaronmgriffin at gmail.com> wrote:
>>>       
>>>> On Mon, Jul 20, 2009 at 4:33 PM, Dan McGee<dpmcgee at gmail.com> wrote:
>>>>         
>>>>> On Mon, Jul 20, 2009 at 3:38 PM, Steven Blatchford<sblatchford at gmail.com> 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