From: "W. Trevor King" <wking@tremily.us>
To: gentoo-portage-dev@lists.gentoo.org
Subject: [gentoo-portage-dev] Re: layout.conf: What's our opinion?
Date: Mon, 20 Jan 2014 18:36:15 -0800 [thread overview]
Message-ID: <20140121023615.GD29063@odin.tremily.us> (raw)
In-Reply-To: <52DD02FA.3040109@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]
On Mon, Jan 20, 2014 at 12:05:30PM +0100, Sebastian Luther wrote:
> Currently layout.conf is not under PMS control. This basically means
> that every PM (or version thereof) may support different keys and
> assign different meanings to them.
Standardizing in the PMS sounds like a good idea, for situations where
a consensus can be reached.
> Portage's behavior for unknown keys in layout.conf is to ignore them
> without a warning.
That makes sense, and is a good practice for forwards-compatibility
[1]. Repositories providing custom keys (or package managers
supporting custom keys) do so with the understanding that there may be
incompatibilities. Namespaced custom keys (portage-eclass-masters?)
would help avoid accidental collision. Versioning the layout.conf key
spec would also be useful, so a PM in strict-mode could warn “unknown
keys x, y, and z in a v1.2 layout.conf. I only understand v1.0, and
it's possible that these keys have been added in subsequent versions”.
> The bad thing about this is that some layout.conf keys portage
> currently supports, may render the repository unusable for a PM if
> it doesn't support them.
Can you give an example of the breakage? Maybe I just haven't been
listening in the right places. If the problem is that the
repositories *need* a custom key that is not universally supported,
then that seems like something the repository authors should expect.
> After discussing this one IRC I came to the conclusion that we just
> disagree on how we should handle additions to layout.conf.
>
> Basically it's either
> 1) "We add things as we see fit." or
> 2) "We should only add things if absolutely necessary.".
Locking everything down completely seems overly harsh, and makes it
harder to experiment with new features. Why not:
1.5) We can add custom keys as we see fit under the ‘portage-*’
namespace.
* Portable repositories should not rely on them until they land
in the PMS under a new layout.conf version, at which time the
‘portage-’ prefix will be removed.
* Portage will recognize any newly standardized keys under their
old ‘portage-*’ name to allow repositories to gracefully
transition to the standardized names.
Cheers,
Trevor
[1]: http://www.w3.org/2001/tag/doc/versioning-20070326.html#iddiv470454016
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-01-21 2:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-20 11:05 [gentoo-portage-dev] layout.conf: What's our opinion? Sebastian Luther
2014-01-20 11:43 ` Alexander Berntsen
2014-01-21 2:36 ` W. Trevor King [this message]
2014-01-21 3:27 ` Mike Frysinger
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=20140121023615.GD29063@odin.tremily.us \
--to=wking@tremily.us \
--cc=gentoo-portage-dev@lists.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