[gentoo-dev] [rfc] paludis and portage in gentoo statistics
hi there! intro + high level stuff = the stats gathering project that i'm currently working on mainly involves data specific to the package manager, i.e. portage. as some gentoo users are using paludis instead of portage the question arises if and how we should integrate data submitted from machines using paludis or even paludis and portage in parallel. it might be good to be clear about this before the actual launch of the service to do better long term design decisions, even if paludis support is beyond the scope of the GSoC project. that's why i bring the topic up now. any ideas or advice on how we could or should handle that or what to avoid? implementation == a few variables in portage that do not have a direct equivalent in paludis: - ACCEPT_KEYWORDS: deduce from '*/*' line in platforms.conf? - ARCH: deduce from CHOST and deduced ACCEPT_KEYWORDS - SYNC: not deducable atoms in paludis seem to be a superset of portages. if so that would not cause any trouble so far. any technical differences that you consider to become a problem? thanks in advance, sebastian
Re: [gentoo-dev] [rfc] paludis and portage in gentoo statistics
On Tue, 04 Aug 2009 18:31:21 +0200 Sebastian Pipping webmas...@hartwork.org wrote: implementation == a few variables in portage that do not have a direct equivalent in paludis: - ACCEPT_KEYWORDS: deduce from '*/*' line in platforms.conf? What do you need this for? It's a fairly meaningless bit of information now that there's package.keywords for Portage. - ARCH: deduce from CHOST and deduced ACCEPT_KEYWORDS You can get the value of the ARCH var used to install Paludis. - SYNC: not deducable Sure it is. Ask a repository if it has a metadata key named 'sync', and use what it returns. atoms in paludis seem to be a superset of portages. if so that would not cause any trouble so far. Not quite. We treat =* things differently depending upon context (they mean the thing that makes sense when used in user config files, and only emulate Portage weirdness when handling EAPI controlled things). any technical differences that you consider to become a problem? You seem to be hitting upon it with the 'global configuration' things. Pretty much everything in Paludis is a per-package setting, with wildcards being how you apply settings broadly. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [rfc] paludis and portage in gentoo statistics
On Tue, Aug 04, 2009 at 08:58:48PM +0100, Ciaran McCreesh wrote: On Tue, 04 Aug 2009 18:31:21 +0200 Sebastian Pipping webmas...@hartwork.org wrote: You seem to be hitting upon it with the 'global configuration' things. Pretty much everything in Paludis is a per-package setting, with wildcards being how you apply settings broadly. Same with pkgcores internals; portage configuration format may have a global, but that doesn't mean a global has to exist in pkgcore installations. ~brian pgptvgLj6A02Q.pgp Description: PGP signature
[gentoo-dev] gcc-4.4 unmasking soon
I'd really like to unmask gcc-4.4.1 soon, as in the next week or so. If you could please install it and test it out, I would appreciate it. Also, if you have any gcc 4.4 porting bugs assigned to a herd that you are a part of, resolving those bugs would help a lot. Thanks to all that have contributed and helped already, -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpTWFS2O2djB.pgp Description: PGP signature
Re: [gentoo-dev] gcc-4.4 unmasking soon
Hi! I'm already use gcc-4.4.0/gcc-4.4.1 and whole system was rebuild with new gcc (including kde-4.2.x/4.3.x and openoffice). Also i noticed that some scientific software works better with gcc-4.4.x (like gromacs and gamess) On Среда 05 августа 2009 05:15:57 Mark Loeser wrote: I'd really like to unmask gcc-4.4.1 soon, as in the next week or so. If you could please install it and test it out, I would appreciate it. Also, if you have any gcc 4.4 porting bugs assigned to a herd that you are a part of, resolving those bugs would help a lot. Thanks to all that have contributed and helped already, -- Alexey 'Alexxy' Shvetsov Gentoo/KDE Gentoo/MIPS Gentoo Team Ru signature.asc Description: This is a digitally signed message part.
