From: Brian Harring <ferringb@gmail.com>
To: gentoo-dev@lists.gentoo.org
Cc: zmedico@gentoo.org
Subject: Re: [gentoo-dev] Gentoo Council Reminder for February 26
Date: Tue, 24 Feb 2009 09:47:25 -0800 [thread overview]
Message-ID: <20090224174725.GC3506@hrair> (raw)
In-Reply-To: <20090223072648.GK12339@hermes>
[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]
On Sun, Feb 22, 2009 at 11:26:48PM -0800, Donnie Berkholz wrote:
> This is your friendly reminder! Same bat time (typically the 2nd & 4th
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> irc.freenode.net) !
Informal request, but it would be useful to get an idea of the
councils views on portage overlay compatibility issues.
Specifically, when it comes to gentoo repositories, there is one, and
only one definition of what that is- pms's repo spec. The problem
here is that the only repository truly conformant to that spec is
gentoo-x86, for the rest of the repositories (overlays realistically)
whatever portage supports seems to be the eventual standard they grow
towards.
Problem with this is that there is *zero* way to spot these non-pms
repositories as it stands. Simplest example, under portage overlays
can unmask pkgs globally (gnome overlay reverting masks in
gentoo-x86), package.unmask exists/works, package.keywords
exists/works, and package.mask can be a directory.
I've not traced through the mess of config's __init__ to verify
*every* pms noncompliance there, but I'd assume there are definitely a
couple more hanging around to blow up in alt managers faces.
At the very least I'm after having the non-pms repos marked in some
fashion so that alt implementations don't have to assume the portage
standard (rather then the *agreed to* pms standard) to avoid
exploding, but that's a rather short sighted solution- something is
needed long term.
Either way, I'd be curious about the councils *informal* opinion on
the overlay issue.
thanks,
~harring
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-02-24 17:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-23 7:26 [gentoo-dev] Gentoo Council Reminder for February 26 Donnie Berkholz
2009-02-24 17:47 ` Brian Harring [this message]
2009-02-24 18:01 ` Santiago M. Mola
2009-02-25 12:42 ` Gilles Dartiguelongue
2009-02-25 12:56 ` Brian Harring
2009-02-25 7:12 ` Donnie Berkholz
2009-02-25 11:06 ` Petteri Räty
2009-02-25 12:16 ` [gentoo-dev] Open council spot Torsten Veller
2009-02-26 19:02 ` [gentoo-dev] Gentoo Council Reminder for February 26 Luca Barbato
2009-02-26 19:19 ` Donnie Berkholz
2009-02-26 19:22 ` Ciaran McCreesh
2009-02-26 19:34 ` Luca Barbato
2009-02-26 19:38 ` Ciaran McCreesh
2009-02-26 20:40 ` Luca Barbato
2009-02-27 20:23 ` Ciaran McCreesh
2009-02-28 13:04 ` Regarding live sources management proposals (Was: [gentoo-dev] Gentoo Council Reminder for February 26) Luca Barbato
2009-02-26 19:23 ` [gentoo-dev] Gentoo Council Reminder for February 26 Donnie Berkholz
2009-02-26 19:39 ` Brian Harring
2009-02-25 14:22 ` Nirbheek Chauhan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090224174725.GC3506@hrair \
--to=ferringb@gmail.com \
--cc=gentoo-dev@lists.gentoo.org \
--cc=zmedico@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox