[gentoo-dev] [rfc] paludis and portage in gentoo statistics

[gentoo-dev] [rfc] paludis and portage in gentoo statistics

[Sebastian Pipping]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

On Tue, 04 Aug 2009 18:31:21 +0200
Sebastian Pipping <webmaster@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [rfc] paludis and portage in gentoo statistics

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

On Tue, Aug 04, 2009 at 08:58:48PM +0100, Ciaran McCreesh wrote:
> On Tue, 04 Aug 2009 18:31:21 +0200
> Sebastian Pipping <webmaster@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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]