[pacman-dev] architecture warn/check

Aaron Griffin aaronmgriffin at gmail.com
Mon Jul 20 18:28:13 EDT 2009


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.


More information about the pacman-dev mailing list