From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: new profile layout with flavors and mix-ins
Date: Thu, 3 Jul 2014 08:53:06 +0000 (UTC) [thread overview]
Message-ID: <pan$72d64$b7a9a0a1$44d99200$174e2bbe@cox.net> (raw)
In-Reply-To: 53B4FF82.4020309@gentoo.org
Michael Haubenwallner posted on Thu, 03 Jul 2014 09:00:18 +0200 as
excerpted:
> What about making /etc/portage/make.profile a directory rather than a
> symlink, having /etc/portage/make.profile/parent to reference all the
> flavours?
We /almost/ have that already. I've long thought that /etc/portage/
profile should be the "real" profile instead of an override of the real
profile, in which case it would have a parent file as you suggested,
which could have multiple listed parents.
Then /etc/portage/make.profile could be done away with, or more likely at
least for a time, for compatibility reasons simply be a symlink
-> profile.
Then users would simply directly modify their /etc/portage/profile
profile, including its parent file, as desired, instead of having the
/etc/portage/make.profile symlink, with /etc/portage/profile being yet
another layer on top of that.
For all I know that might actually work right now as I've not tried it,
but the portage (5) manpage does specifically say /etc/portage/profile
supports all profile files EXCEPT parent, so unless the documentation is
wrong...
Assuming the documentation is correct, however, "all" we'd need to do on
the user side would be to make portage and the other tools treat the
parent file in /etc/portage/profile just as they do in other profile dirs,
create an eselect module or equivalent to help manage that parent file,
and update the documentation including the handbook accordingly.
Updating other tree related tools would be required as well, of course,
but as already pointed out, the real work would probably be in designing
and setting up the new "flatter" profile tree layout and finding the
appropriate new-layout location for all the existing settings.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2014-07-03 8:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-02 15:44 [gentoo-dev] new profile layout with flavors and mix-ins William Hubbs
2014-07-02 17:54 ` Michał Górny
2014-07-02 18:10 ` Rich Freeman
2014-07-02 18:32 ` Anthony G. Basile
2014-07-02 18:35 ` Rich Freeman
2014-07-02 18:41 ` Rick "Zero_Chaos" Farina
2014-07-02 19:07 ` Anthony G. Basile
2014-07-02 19:19 ` Rick "Zero_Chaos" Farina
2014-07-02 19:30 ` Rich Freeman
2014-07-03 14:55 ` Andreas K. Huettel
2014-07-03 23:09 ` Tom Wijsman
2014-07-03 23:35 ` Rich Freeman
2014-07-03 6:18 ` Joshua Kinard
2014-07-03 7:00 ` Michael Haubenwallner
2014-07-03 8:47 ` Joshua Kinard
2014-07-03 16:06 ` Ian Stakenvicius
2014-07-03 8:53 ` Duncan [this message]
2014-07-03 9:01 ` [gentoo-dev] " Martin Vaeth
2014-07-03 7:32 ` [gentoo-dev] " Michał Górny
2014-07-03 8:21 ` Joshua Kinard
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='pan$72d64$b7a9a0a1$44d99200$174e2bbe@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-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