| View previous topic :: View next topic |
| Author |
Message |
muaddib7
n00b
Joined: 02 Sep 2005
Posts: 21
Location: Athens, Greece
|
 Posted: Thu Oct 06, 2005 1:15 pm Post subject: Maintaining the ebuilds |
 |
|
Hi guys
I have tried to find some relevant post but I could not find any on the following issue:
Due to the nature of my work I have access to multiple machines of "non-standard" architectures. The range comprises of Itaniums, MIPS and PA-Risc iron and I have installed with full or partial success Gentoo on them. My main issue is that most ebuilds lack the keywords for these architectures...
Now don't get me wrong. I am not talking about binary libraries etc, but I fail to see how phpBB does not have the ia64 keyword for example. I do understand that the maintainers just have too much stuff on their hands. However we should be able to help out with specifying our level of success with emerging some packages in up-till-that-moment unsupported architectures.
I know there is bugzilla, but it would be better to have some relevant links on the main ebuild database exactly for this purpose.
I still might have missed such a link or feature so please inform me. |
|
| Back to top |
|
 |
mark_alec
Bodhisattva
Joined: 11 Sep 2004
Posts: 6066
Location: Melbourne, Australia
|
| Posted: Thu Oct 06, 2005 1:37 pm Post subject: |
|
|
Unfortunately if a developer hasn't successful compile a package on any given architecture, they cannot add the keywords for that arch. With the massive amounts (~9000) packages in the tree, for any arch but x86 it is impossible with current staffing to keyword everything.
If you wanted to help, you could add the keywords yourself and test to see if the package builds. If it does, report so at bugs.gentoo.org. You may also consider becoming a developer or arch tester so that you can more easily assist gentoo in keywording packages for you architectures. |
|
| Back to top |
|
|
muaddib7
n00b
Joined: 02 Sep 2005
Posts: 21
Location: Athens, Greece
|
| Posted: Thu Oct 06, 2005 2:06 pm Post subject: |
|
|
Ok
Compiling is a misleading word as you understand... installing www-apps/egroupware when the apache, mysql and php ebuilds are at least in ~ia64 has nothing to do with compiling. The application is a script and it would be very hard to find something that is architecture specific. It even runs on windoze 
I could go in bugs.gentoo.org and post a bug with the added keyword. However having already posted a bug for another ebuild I can see that there are not enough people. On the other hand I cannot just drop and say "People I am installing www-apps ebuilds on alternate architectures so make me a developper..." I think more than that is needed... or not?
I have some time for testing such packages and I can help out if the devs wanted. However I would hardly consider myself a dev in that case  |
|
| Back to top |
|
|
tunkaflux
Tux's lil' helper
Joined: 20 Aug 2003
Posts: 76
|
| Posted: Thu Oct 06, 2005 5:22 pm Post subject: |
|
|
muaddib7, be patient  I have only Sparc and Alpha to toy with and there are not enough developers for these systems... However, from what I could hear/read on irc, they are working on it and soon there should be more Arch Testers...
Maybe a dev can enlighten us? |
|
| Back to top |
|
|
Ferdy
Retired Dev
Joined: 04 May 2002
Posts: 483
Location: España
|
| Posted: Thu Oct 06, 2005 7:22 pm Post subject: |
|
|
Scripts are not guaranteed to be arch independent.
And yes, I'm personally working on the Alpha Arch Testers project.
Cheers,
Ferdy |
|
| Back to top |
|
|
muaddib7
n00b
Joined: 02 Sep 2005
Posts: 21
Location: Athens, Greece
|
| Posted: Thu Oct 06, 2005 10:24 pm Post subject: |
|
|
| Ferdy wrote: | Scripts are not guaranteed to be arch independent.
And yes, I'm personally working on the Alpha Arch Testers project.
Cheers,
Ferdy |
I stand partially corrected... it depends on the modules/libraries the web-app needs from the underlying system. So if imap support for php-x.x.x is buggy and I want to install the latest egroupware I might have a problem. However this might also be interpreted in a different fashion. egroupware ebuild should have dependencies based on the use flags given, and if emerge does not solve them then the installation will not proceed.
especially for scripting languages the logic behind the masking/missing-keywords should be moved from the package to the libraries and the required support from the language itself. so it boils down to hunting and finding all the dependencies needed for the various features of the webapp. I would think though that putting webapps like egroupware on testing would be more productive bug-finding-wise as people would be able to hunt down missing features and establish missing/failing dependencies. |
|
| Back to top |
|
|
Kloeri
Retired Dev
Joined: 02 Sep 2002
Posts: 144
|
| Posted: Thu Oct 06, 2005 10:48 pm Post subject: |
|
|
| muaddib7 wrote: | I stand partially corrected... it depends on the modules/libraries the web-app needs from the underlying system. So if imap support for php-x.x.x is buggy and I want to install the latest egroupware I might have a problem. However this might also be interpreted in a different fashion. egroupware ebuild should have dependencies based on the use flags given, and if emerge does not solve them then the installation will not proceed.
|
I might simply be understanding you.. but applications written in portable languages isn't guaranteed to work on a given arch even if that arch supports all the needed dependencies / libraries of that application. Consider some application written in a script language that accesses /proc.. Even if the scripting language used is portable the application probably isn't because of the /proc access.
That's why the arch maintainers are always screaming at people telling them that applications written in PHP or other languages is portable and should be stabled without testing by the arch team. A good example of a completely arch dependend PHP application is dev-php/phpsysinfo. |
|
| Back to top |
|
|
muaddib7
n00b
Joined: 02 Sep 2005
Posts: 21
Location: Athens, Greece
|
| Posted: Fri Oct 07, 2005 7:08 am Post subject: |
|
|
| Kloeri wrote: | I might simply be understanding you.. but applications written in portable languages isn't guaranteed to work on a given arch even if that arch supports all the needed dependencies / libraries of that application. Consider some application written in a script language that accesses /proc.. Even if the scripting language used is portable the application probably isn't because of the /proc access.
That's why the arch maintainers are always screaming at people telling them that applications written in PHP or other languages is portable and should be stabled without testing by the arch team. A good example of a completely arch dependend PHP application is dev-php/phpsysinfo. |
You are right, however my examples where not for such exotic apps. Accessing information directly from the /proc is after all bad practice. BUT my question was not meant to question the inclusion of arch or ~arch in a given ebuild; I just proposed that we had a formal way, either in specific forum posts or in specific bugs in bugzilla, to say that a certain package without the keywords has been compiled/installed and that this parctice should be advertised so that people can cotribute a "worked for me as well" or a "could not make it to work".
I currently have installed more than 10 apps without ia64 or ~ia64 and some of them have been used for some time. All this info is basically lost, if such a practice is not institutionalized. |
|
| Back to top |
|
|
Kloeri
Retired Dev
Joined: 02 Sep 2002
Posts: 144
|
| Posted: Fri Oct 07, 2005 6:35 pm Post subject: |
|
|
| muaddib7 wrote: | | I currently have installed more than 10 apps without ia64 or ~ia64 and some of them have been used for some time. All this info is basically lost, if such a practice is not institutionalized. |
Please file keyword requests on https://bugs.gentoo.org. It sometimes takes us a while to get around to keywording bugs but we will eventually get around to processing them |
|
| Back to top |
|
|
|
Gentoo on Alternative Architectures
