is there a script to add amd64 to all package keywords

RedBeard0531 · Guru Joined: 21 Sep 2002 Posts: 415 Location: maryland

it would be nice to not have to do it manually. It could also show the amd64 team that it could be done w/o too much more. I asked them to add ~amd64 to all packages and then change it to -amd64 if they get reports of breakage. Un fortunately they said it would be too much work.

I think it could be done with sed somehow, but i dont know how to use it. Basikley it should find every package with a line that starts with KEYWORDS=" and has x86 on that line, but not amd64. That doesnt seem too complex to me, but like i said I dont know sed

.
_________________
OH MY GOD! Kenny just killed Kenny!
That Basterd!

Pythagoras1 · Posted: Sat Jun 12, 2004 3:29 pm Post subject:

you could add x86 and ~x86 to your ACCEPT_KEYWORDS.
then someone could post which applications do work on amd64 and after that these ebuilds should get the ~amd64 certificate.

C.W. · n00b Joined: 27 May 2004 Posts: 74

Kugelfang · Posted: Sat Jun 12, 2004 6:52 pm Post subject:

Pythagoras1: Really, REALLY bad idea...
Don't ever put anything else in your ACCEPT_KEYWORDS than your ${ARCH}. So on amd64, it is amd64 and ~amd64, nothing else.

There a patches and configure options that depend on ${ARCHS}. So an ebuild containing

Pythagoras1 · Posted: Sat Jun 12, 2004 7:13 pm Post subject:

oops, thanks for that information. i forgot that there are ebuilds with (~)amd64 too :roll:

however, in this case it would make more sense to apply these flags on the command line if an ebuild is masked for amd64.

borh · Posted: Sun Jun 13, 2004 6:13 pm Post subject:

I use this bash script to unmask packages in /usr/portage :

MarkKikken · n00b Joined: 24 May 2004 Posts: 13

Well, so far i've done multiple things to get masked apps working on my AMD64 system. I've put stuff in ACCEPT_KEYWORDS and edited the portage tree. The first feels too "ad-hoc" to me and the second gives me the feeling I'm messing my system up (not entirely untrue).

Anyway, I think the portage system can be improved here. Maybe somewhere in portage (I'm no expert on how the portage system works) installed packeges should be able to have a "testing"-flag aciociated with them. That way portage will know what you're doing with those packages. At first it will probably do nothing with this data, but it could be very useful.
For example: if options could be added to emerge, so that you can specify if it is allowed to put packages in "testing" mode. Or only do this with masked packages, or only if otherwise dependancies cannot be resolved. Or it could ask the user in that case. And since it stores wich packages are being tested, you could even allow to use testing only for packages that a package that's already being tested depends on.

Ok to sum it up: store if something unstable is being tested and add lots of options to emerge to make emerge understand exactly what packages you want to test.

But there is more. Once you have this data, a user could generate reports from this data. Things like: What packages have been tested? Did the package compile? Was it removed afterwards (so, it probably didn't work)? One could even store bug-reports with this data and include them in the report.
The user could then submit these reports to the Gentoo cummunity, thereby informing the community members of more package-stability statistics. I agree, this should never, ever, be automated, to protect the user's privacy. The user has to run the program himself and publish the data himself.
The big advantage would simply be that it is easy to post data. I've tested quite a few packages on my amd64. But I haven't kept track of everything that worked and didn't work. Though I would like to inform the community of my findings, that would just be too much work. With a system like i've described here, it would be easy.

So, what do you think of it?

RedBeard0531 · Guru Joined: 21 Sep 2002 Posts: 415 Location: maryland

MarkKikken · n00b Joined: 24 May 2004 Posts: 13

I haven't checked for replies here for a while, but back then I was serious about this. BTW: What do you mean by GELP?

But now I've found out that the /etc/portage/packages.keywords file basicly does what I was proposing here: A list of packages that are being tested on the system. What portage lacks is an easy way for users to report successes or faillures with certain packages on certain architectures. I've found quite a number of packages that work (to some extend) on amd64, but have not been marked accordingly. Better feedback from users could improve the situation.

If you put them all in packages.keywords, you will have a list of them at hand whenever you need it. However, you will still have to find out what version of the package is installed and if it runs stable. Portage should be able to log somewhere if it compiled cleanly. A report of the installed versions should be possible to produce as well. Furthermore, bug-tracking tools could be more tightly integrated with the system, so in the event of a crash the user can report this.
The basic idea is: make it easier for users to contribute stability information.

BTW: why is the /etc/portage/packages.keywords file not present by default?

bverheg · n00b Joined: 01 Sep 2002 Posts: 39 Location: Vlaanderen

That should have been GLEP.
http://www.gentoo.org/proj/en/glep/

RedBeard0531: I too think there should be a keyword for each ARCH in each ebuild. Either ARCH, ~ARCH or -ARCH. Maybe you should enter a GLEP about it.

MarkKikken: I agree. I have successfully emerged lots of packages after adding ~amd64 keyword. On some occasions I have reported this on bugzilla, but many times I just didn't bother because of the tedious work involved.
It would be nice to have a simple 'report-succesful-emerge' command doing this with less hassle.

Kow · Apprentice Joined: 28 Dec 2003 Posts: 227

You wouldnt want to add anything x86 to accept keywords - some packages amd64 and x86 completely change things ... *cough java.
_________________
-Kow