how to deal with x86_64 and AUR

AndyRTR · 2006-05-10 05:52:51

It's not far away the x86_64 port will become an official part of archlinux. We(better I) try to make it as much as possible similar to arch32.

I will cleanup the x86_64 community repo so it will only contain supported packages. But how to deal with unsupported pkgbuilds?

Will we get our own AUR? Or how can we mark pkgbuilds to let users know if the package will build on x86_64 without modifications(tag "arch"?) or how to modify the pkgbuilds? An option in the search function would also be nice.

Andy64RTR

iphitus · 2006-05-10 07:46:25

that's an interesting problem. i think a seperate aur is overkill, as many packages that would build on x86 also would build on x86_64.

it'd probably be better to add x86_64 to the existing aur in some way.

James

Mr Green · 2006-05-10 09:52:05

If a flag is going to be added to pkgbuild then AUR could warn pkg is for x86 or x86_64 and aurbuild could be hacked to pick up given arch types ...

I agree two AUR's is not the ideal solution

jakob · 2006-05-10 20:09:51

What about a ckeckbox the PKGBUILD maintainer is able to activate which adds a little icon or text in the line of the pkg in aur overview?

kill · 2006-05-10 21:01:57

Here is another interesting question. How are PKGBUILD maintainers without a 64 bit Arch install or vice versa going to be able to check if a package will compile and run on the other platform? I ask because for the longest time Open Office would not build on a 64 bit platform.

AndyRTR · 2006-05-10 21:13:39

kill wrote:

Here is another interesting question. How are PKGBUILD maintainers without a 64 bit Arch install or vice versa going to be able to check if a package will compile and run on the other platform? I ask because for the longest time Open Office would not build on a 64 bit platform.

i686 devs != x86_64 devs :!:

But you are right there will be a way they can crossbuild packages. We think about using pacbuild for that. But this will only be for the official repos. It has nothing to do with AUR.

For AUR there could be a checkbox to mark on what architectures it will compile and run. The maintainer and TURs should have access to mark/unmark those checkboxes. The searchfunction should take care of it.

kill · 2006-05-11 00:37:34

AndyRTR wrote:

i686 devs != x86_64 devs :!:

i686 AUR == x86_64 AUR.
Now the question clarified. How will an AUR who only has an i686 install know that a package will compile and run on x86_64 without being able to test it? Marking which arch it will work on is all well and good if they know it will actually work on that arch.

iBertus · 2006-05-11 01:35:27

A vote for only having a single AUR with some sort of flag to alert users to the architecture.This is also a problem for pre-built packages, as there is no filename difference currently and most people probably wouldn't care to check by pacman -Qi/Si.

Dusty · 2006-05-11 03:09:36

Allow the users to flag packages as working or not working on a specific architecture. Add a column or two to the DB and basically its like voting. May as well save the TUs some work and having 64 bit specific TUs.

Dusty

Mr Green · 2006-05-11 06:40:39

Dusty wrote:

Allow the users to flag packages as working or not working on a specific architecture. Add a column or two to the DB and basically its like voting. May as well save the TUs some work and having 64 bit specific TUs.
Dusty

Yeah what he said ..... 8)

Cerebral · 2006-05-11 12:58:36

Additionally, if a certain package needs different build procedures for x86 and x86_64, will the AUR need to be able to allow two different 'versions' of the same-named package, each flagged for a different architecture, to be available simultaneously? Or is it always the case that if someone fixes an x86 package to build on x86_64, the 'fixed' package will still build on x86 as well?

AndyRTR · 2006-05-11 14:30:25

look at this pkgbuild.

we keep it building on i686 architecture to have one common pkgbuild. it should be always possible to have one common pkgbuild.

there are already packages that will never build on x86_64(skype, kernel24 depending....). but it will soon happen that users will add packages that are completly x86_64 (32bit compatibility stuff - that i don't like). So it must be possible to have x86_64 only packages.

And for all: keep in mind that we also have a ppc port ;-)

neotuli · 2006-05-16 03:57:43

My approach to this problem, which I think I pondered a while back, is to just keep things as they are. It is true that most aur submitters cannot check their package on other architectures. However, it is also true that a generic PKGBUILD *should* work across most architectures for the vast majority of packages. I don't see why people can't just submit whatever additions are needed in the comments for each package, and the maintainer can incorporate them as needed. I don't think the extra flags are worth the hassle, just as multiple AURs are not.

As for the packages in community, I think the best course of action is to have our TUs take care of the i686 packages, and we can get it set up so the arch64 guys can make any needed tweaks and mirror whatever packages they'd like.

Both of these are pretty good, simple longterm solutions. But obviously nothing is written in stone.

AndyRTR · 2006-05-16 05:10:24

There are plans for porting the supported community repo to x86_64. A special TU would be nice as you TUs are very activ.

For unsupported AUR I suggest using an arch variable in the pkgbuild so everybody can see for what architecture is was designed. So the one who will initially build it will add

arch=(i686) or arch=(x86_64)

If somebody comments that it builds and works well on another architecture the mainainter may add it to arch=(i686 x86_64). Having the arch variable in every pkgbuild will give us all possibilities for the future using it for scripts, search request, crossbuilding or whatever.

We - the arch64 devs - are just adding that "arch" tag to all packages in current and extra :!:

If you agree to that way we should add the arch variable to the ABS guide.

iBertus · 2006-05-16 15:24:41

AndyRTR wrote:

There are plans for porting the supported community repo to x86_64. A special TU would be nice as you TUs are very activ.
For unsupported AUR I suggest using an arch variable in the pkgbuild so everybody can see for what architecture is was designed. So the one who will initially build it will add
arch=(i686) or arch=(x86_64)
If somebody comments that it builds and works well on another architecture the mainainter may add it to arch=(i686 x86_64). Having the arch variable in every pkgbuild will give us all possibilities for the future using it for scripts, search request, crossbuilding or whatever.
We - the arch64 devs - are just adding that "arch" tag to all packages in current and extra :!:
If you agree to that way we should add the arch variable to the ABS guide.

This makes sense, as you wouldn't break anything by adding another variable to the PKGBUILD.

Dusty · 2006-05-16 15:27:43

iBertus wrote:

This makes sense, as you wouldn't break anything by adding another variable to the PKGBUILD.

Barring simplicity. :-(

I agree this is the best option, its just such a shame that the cross-architectural stuff is making the whole system so much more complicated than it once was.

Dusty

AndyRTR · 2006-05-16 15:53:44

I've added the arch variable to the ABS wiki section.

It would be nice to have the arch section shown on the website when watching pkg details. Maybe somewhere near dependencies and sources.

Mr Green · 2006-05-16 15:56:53

Dusty wrote:

iBertus wrote:
This makes sense, as you wouldn't break anything by adding another variable to the PKGBUILD.
Barring simplicity. :-(
I agree this is the best option, its just such a shame that the cross-architectural stuff is making the whole system so much more complicated than it once was.
Dusty

emmm fruggy adds arch. (x86_64) to pkg name not sure thats any better :?

iBertus · 2006-05-16 21:14:59

Dusty wrote:

iBertus wrote:
This makes sense, as you wouldn't break anything by adding another variable to the PKGBUILD.
Barring simplicity. :-(
I agree this is the best option, its just such a shame that the cross-architectural stuff is making the whole system so much more complicated than it once was.
Dusty

I agree, things are getting more complicated. However, I've got confidence that this community can manage to keep everything more orderly than other distros have managed.

dsa · 2006-06-09 19:28:50

Im making some changes in AUR to enable architecture flagging.

Im trying to let you have the same packages but with different architectures. Is it the desired behaviour ?

dsa · 2006-06-09 19:32:23

Another question... What about the arch variable in the PKGBUILD ? I can assume it will have it ?

AndyRTR · 2006-06-10 08:43:50

Not sure what you mean. Do you plan to change the AUR frontside?

dtw · 2006-06-10 11:54:24

I have had a pretty good read of this thread (not detailed) but I think some of you guys have overlooked something, though it may be moot now. That oversight is that TUs were never supposed to confirm that every pkg in the AUR actually built. The "flag safe" is purely to confirm that there is no malicious code or otherwise involved.

I just wanted to make that totally clear because some suggestions seem to intimate that we build and check everything - we don't

dsa · 2006-06-10 21:49:54

Hello Andy,

What do you sugest ? Im thinking in changing the frontpage to add a architecture column and to change all the relative pages to support this.

I think that the best choice is to make things work just as they work today, the TUs did not have to check if a package builds, as dibble said, so this should not be our concern.

neotuli · 2006-06-11 17:24:08

dtw wrote:

I have had a pretty good read of this thread (not detailed) but I think some of you guys have overlooked something, though it may be moot now. That oversight is that TUs were never supposed to confirm that every pkg in the AUR actually built. The "flag safe" is purely to confirm that there is no malicious code or otherwise involved.
I just wanted to make that totally clear because some suggestions seem to intimate that we build and check everything - we don't

THANK YOU! Someone around here agrees with my definition of "safe". Hot damn I got yelled at one time for marking something "safe" but I hadn't tried to build it and it turned out that the md5sums didnt match the source it downloaded.

Arch Linux

#1 2006-05-10 05:52:51

how to deal with x86_64 and AUR

#2 2006-05-10 07:46:25

Re: how to deal with x86_64 and AUR

#3 2006-05-10 09:52:05

Re: how to deal with x86_64 and AUR

#4 2006-05-10 20:09:51

Re: how to deal with x86_64 and AUR

#5 2006-05-10 21:01:57

Re: how to deal with x86_64 and AUR

#6 2006-05-10 21:13:39

Re: how to deal with x86_64 and AUR

#7 2006-05-11 00:37:34

Re: how to deal with x86_64 and AUR

#8 2006-05-11 01:35:27

Re: how to deal with x86_64 and AUR

#9 2006-05-11 03:09:36

Re: how to deal with x86_64 and AUR

#10 2006-05-11 06:40:39

Re: how to deal with x86_64 and AUR

#11 2006-05-11 12:58:36

Re: how to deal with x86_64 and AUR

#12 2006-05-11 14:30:25

Re: how to deal with x86_64 and AUR

#13 2006-05-16 03:57:43

Re: how to deal with x86_64 and AUR

#14 2006-05-16 05:10:24

Re: how to deal with x86_64 and AUR

#15 2006-05-16 15:24:41

Re: how to deal with x86_64 and AUR

#16 2006-05-16 15:27:43

Re: how to deal with x86_64 and AUR

#17 2006-05-16 15:53:44

Re: how to deal with x86_64 and AUR

#18 2006-05-16 15:56:53

Re: how to deal with x86_64 and AUR

#19 2006-05-16 21:14:59

Re: how to deal with x86_64 and AUR

#20 2006-06-09 19:28:50

Re: how to deal with x86_64 and AUR

#21 2006-06-09 19:32:23

Re: how to deal with x86_64 and AUR

#22 2006-06-10 08:43:50

Re: how to deal with x86_64 and AUR

#23 2006-06-10 11:54:24

Re: how to deal with x86_64 and AUR

#24 2006-06-10 21:49:54

Re: how to deal with x86_64 and AUR

#25 2006-06-11 17:24:08

Re: how to deal with x86_64 and AUR

Board footer