On Mon, Jul 20, 2009 at 5:12 PM, Aaron Griffin<aaronmgriffin@gmail.com> wrote:

On Mon, Jul 20, 2009 at 4:33 PM, Dan McGee<dpmcgee@gmail.com> wrote:

...

On Mon, Jul 20, 2009 at 3:38 PM, Steven Blatchford<sblatchford@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. -Dan

On Mon, Jul 20, 2009 at 5:28 PM, Aaron Griffin<aaronmgriffin@gmail.com> wrote:

On Mon, Jul 20, 2009 at 5:24 PM, Dan McGee<dpmcgee@gmail.com> wrote:

...

On Mon, Jul 20, 2009 at 5:12 PM, Aaron Griffin<aaronmgriffin@gmail.com> wrote:

...

On Mon, Jul 20, 2009 at 4:33 PM, Dan McGee<dpmcgee@gmail.com> wrote:

...

On Mon, Jul 20, 2009 at 3:38 PM, Steven Blatchford<sblatchford@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. -Dan

Dan McGee wrote:

On Mon, Jul 20, 2009 at 5:28 PM, Aaron Griffin<aaronmgriffin@gmail.com> wrote:

...

On Mon, Jul 20, 2009 at 5:24 PM, Dan McGee<dpmcgee@gmail.com> wrote:

...

On Mon, Jul 20, 2009 at 5:12 PM, Aaron Griffin<aaronmgriffin@gmail.com> wrote:

...

On Mon, Jul 20, 2009 at 4:33 PM, Dan McGee<dpmcgee@gmail.com> wrote:

...

On Mon, Jul 20, 2009 at 3:38 PM, Steven Blatchford<sblatchford@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

Roman Kyrylych wrote:

On Tue, Jul 21, 2009 at 02:18, Allan McRae<allan@archlinux.org> wrote:

...

Dan McGee wrote:

...

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...

Well, I've managed to install i686 pacman-git (replacing old pacman) on my x86_64 system by making a mistake in repo name. :-P

So, you seem a good candidate to do the actual bug report opening so this idea does not get lost! :D Allan

On Tue, Jul 21, 2009 at 15:19, Dan McGee<dpmcgee@gmail.com> wrote:

On Tue, Jul 21, 2009 at 6:22 AM, Allan McRae<allan@archlinux.org> wrote:

...

Roman Kyrylych wrote:

...

Well, I've managed to install i686 pacman-git (replacing old pacman) on my x86_64 system by making a mistake in repo name. :-P

So, you seem a good candidate to do the actual bug report opening so this idea does not get lost!  :D

I did start some preliminary hacking last night on this idea, so it probably won't get lost, but yeah, a bug report would be a good idea.

http://bugs.archlinux.org/task/15622 -- Roman Kyrylych (Роман Кирилич)