Portage profiles re-organization
Daniel Robbins
In preparation for the funtoo-1.0 profile, I am planning to make some
changes to how Portage handles profiles. I have documented the
existing Gentoo functionality, as well as proposed changes, on the
wiki page below:
http://docs.funtoo.org/wiki/Portage_Profiles
Basically, in order to clean up the funtoo-1.0 profile and keep things
clean, I want users to be able to specify more than one profile.
Leveraging the "parent" file seems like the right way to do this. I
think this also cleans up how profiles are defined in Funtoo. I am
also considering moving everything inside /etc/portage while I'm at it
- ie. make.conf and make.globals.
Your comments are welcome.
-Daniel
Jean-Francis Roy
Your comments are welcome.
-Daniel
--
To manage your subscription, visit this group at
http://groups.google.com/group/funtoo-dev?hl=en
---
Also be sure to check out:
Funtoo Forums: http://forums.funtoo.org
Planet Larry: http://larrythecow.org
mat...@progettomio.net
> also considering moving everything inside /etc/portage while I'm at it
> - ie. make.conf and make.globals.
Yes, definitely. it helps new users to understand which files are
related to portage, and makes everything more elegant.
+1 for mv ${related_to_portage} /etc/portage
Don Gray
Sylvain Alain
Like Daniel wrote, I think that /etc/make.conf could become /etc/portage/portage.conf
There's a lot of stuff inside that are related to portage, so why not change the name while we can :P
Giuseppe `ferdy` Miceli
Ciao,
I really love the idea of having all portage related stuff in /etc/portage.
In my humble opinion tho’ - once make.conf and make.profile are moved to /etc/portage the “make” file name gets stronger rationale.
What I mean is that inside /etc/profile obviously there are files related to portage, thus the make.conf and the make.profile are intrinsically bound to portage itself and consequently their filenames make a lot of sense as the “system wide (/etc) portage (/etc/portage) make (/etc/portage/make.conf)” and the “system wide portage profile”.
Speaking of the profile, I am sorry to disagree on the proposed renaming of make.profile. From my perspective users can choose to take advantages of a default system wide profile (which is supposed to reside in the /usr/portage hierarchy) or a personal customized profile (which at this point will be supposed to reside in /etc/portage/make.profile directory). In the first case, make.profile to be a symlink to the actual used profile make a lot of sense. In the second case a make.profile directory will keep a parent file pointing to the default system wide profile(s) supposed to be its heirs.
One small note on the profile.head and profile.tail proposal. I fear that for non-English people they could come out as confusing. Some language associate the meanings of tail and least together, other work the other way around.
I hope I succeeded to throw my two cents in a decent and clear way J
Regards,
--
ferdy
Daniel Robbins
<fe...@ferdy.it> wrote:
> Ciao,
>
> I really love the idea of having all portage related stuff in /etc/portage.
>
> In my humble opinion tho’ - once make.conf and make.profile are moved to
> /etc/portage the “make” file name gets stronger rationale.
Good point, there is nothing wrong with keeping the existing names and
just moving their default location.
> Speaking of the profile, I am sorry to disagree on the proposed renaming of
> make.profile. From my perspective users can choose to take advantages of a
> default system wide profile (which is supposed to reside in the /usr/portage
> hierarchy) or a personal customized profile (which at this point will be
> supposed to reside in /etc/portage/make.profile directory). In the first
> case, make.profile to be a symlink to the actual used profile make a lot of
> sense. In the second case a make.profile directory will keep a parent file
> pointing to the default system wide profile(s) supposed to be its heirs.
Well, I am not sure I understand but just so we are on the same page,
right now, in Portage, /etc/make.profile is typically a symlink, but
if it doesn't exist, Portage looks for /etc/portage/make.profile, and
treats it the same (that is, like /etc/make.profile, it can be a dir
or symlink. But it should be a symlink because any "parent" data is
relative to the CWD. This is where I want to add a feature where "/"
will make it relative to $PORTDIR/profiles, so it can exist as a
normal dir.)
Then, users can define the "last" profile by creating
/etc/portage/profile. In the heirarchy, it is last, or the "tail" of
the list. And make.profile defines the "head" - well, I guess the
"head" of the list is the ultimate parent of make.profile. Maybe that
makes the names technically incorrect. I am not sure if this is what
you are saying or not.
> One small note on the profile.head and profile.tail proposal. I fear that
> for non-English people they could come out as confusing. Some language
> associate the meanings of tail and least together, other work the other way
> around.
OK, but I think it would be good to simplify the names. There is
nothing in "profile" that says "this is a user-defined profile" as
compared to "make.profile". So it is a bit vague. I think it would be
good to give them clear names to make it more obvious what they do.
> I hope I succeeded to throw my two cents in a decent and clear way J
Overall this is good critical feedback that made think. Please feel
free to elaborate further on the points I might have missed.
I did a lot of work today on getting the code ready for an initial "/"
in "parents" files meaning "from $PORTDIR/profiles":
https://github.com/funtoo/portage-funtoo/commit/fa6344c5a94c807f9eadd468f41fec981166baaa
These changes were kind of painful to make but were necessary to get
the code more understandable and manageable, and to allow the Portage
repository to be initialized sooner so that Profiles could be made
repository-aware.
-Daniel
Oleg
gentoo/funtoo/*nix understand what head and tail means :) I guess,
there will be painless migration to new profile and portage, Daniel
making incredibly good documentation and howto's.
Giuseppe `ferdy` Miceli
I will try to summarize through pointed list to better explain my view.
1. moving everything related to portage to /etc/portage.
Seems to be a widely appreciated idea and I can only agree on such change.
/etc contains system wide configuration files and /etc/<dirname> commonly
contains system wide configuration files for a particular
program/application.
2. renaming make.conf and make.profile after having moved them to
/etc/portage.
I think that's more a personal taste issue. I like those filenames since
they reminds me I have to tweak the first one for customization while I have
to change the profile (by hand of via eselect).
But, just indeed, it's mostly a matter of taste. I think I would get used
fairly quick to any other choice.
I still doesn't really like the tail/head, in a manner of speaking
first/last could be even better. I fear they are not such a straight-way
meaning; even also because - as far as I know - there are no configuration
files with tail/head extension in filesystem (usually afaik, head/tail are
basename for piece of text/code to be automatically inserted and don't
really transmit a sense of chronology, more of spatial order).
p.s. I know this is prolly just a semantic/linguist querelle, thus I won't
get offended should you guys just tell me to shut up :-)
Some other scenarios came to my mind:
2.a. /etc/portage/profile.default as a symlink to the
/usr/portage/profiles default profile and /etc/portage/profile.user (if
exists) as a director containing the user profile files;
2.b. force /etc/portage/make.profile to be a directory and by
default cointaining a parent file pointing to the default profile in
/usr/portage/profile (and you can tweak by hand or via eselect the content
of /etc/portage/make.profile/parent and add the other personal specific
profile files in this directory).
3. have portage fully understand the initial slash in the parents files.
I think that's a really sane idea. Lot of work - I have seen - but surely to
be blessed.
4. backward compatibility
As someone else correctly suggest, we have to deal with compatibility with
portage tools (eselect just to name one).
Regards,
--
Ferdy
https://github.com/funtoo/portage-funtoo/commit/fa6344c5a94c807f9eadd468f41f
ec981166baaa
-Daniel
--
Jonas Bernoulli
The discussion so far was focused on moving files to /etc/portage (I also
agree this is a good thing) and renaming the moved files (which I don't
care about much).
I would like to focus on something else but a visual comment on head/tail
first:
/etc/portage/make.profile <- profile.head <- HEAD
/etc/portage/profile <- profile.tail
...
default/linux
base <- TAIL
The profile.user and profile.default names suggested by Giuseppe make more
sense to me.
A major problem with portage's config files is that there currently are
three kinds of configuration directories. (Well actually there are more
but let's focus on those.)
- /usr/portage/profiles/*
- /etc/portage/profile
- /etc/portage
I think the first two should behave the same way. Currently one crucial
difference between the two is that the regular profile directories can
have parents while the parent file is ignored inside /etc/portage/profile.
You want users to edit /etc/portage/profile.head/parent to combine
multiple profiles (like arch, flavor...). This is a very good idea and
supporting it should be fairly trivial, I am just mentioning the above
problem because you seem to have overlooked that it isn't supported yet
as you also said:
"Add /etc/portage/profile.tail to replace /etc/portage/profile -
functionally identical."
Of all the proposed changes I think allowing user to combine multiple
profiles in an easy way is the most important. It has always bothered me
(and apparently Daniel too) that the subdirectories of default/linux are
pretty much identical except that they point to different arch profiles.
Once this duplication can be removed developers are possibly more motivated
to add more "flavors" as they don't come with such a large overhead anymore.
Supporting "parent" inside /etc/portage/profile also allows users to do a
bit more complex things that are best not done in a single profile - like
e.g. defining their *own* flavor profiles.
This leads to the question: why is /etc/[portage]/(make.profile|profile.tail)
needed at all? While I think the profile.(head|tail) terminology is a bit
unfortunate the bigger problem is that there is no single "root node" but
two instead. This is confusing and I am guessing that this is the result of
/etc/portage/profile being added later (or wasn't it?) to accommodate users
who wanted to modify things that weren't supported in /etc/portage.
To take this even further: why not make even /etc/portage/ itself and
/etc/make.profile/ support the same files? I think this would simplify
things quite a bit, and make some of the improvements suggested by Daniel
unnecessary. E.g. no need to worry whether tail/head terminology makes
sense or not - instead there is just /etc/portage/parent. That and
/etc/portage/(make|portage).conf
Currently there are quite a few differences though:
--- files-in-etc-make.profile
+++ files-in-etc-portage
-deprecated
-eapi
-make.defaults
-packages
-packages.build
+bashrc
+categories
+color.map
+make.conf
+mirrors
+modules
package.accept_keywords
+package.env
package.keywords
+package.license
package.mask
-package.provided
+package.properties
package.unmask
package.use
-package.use.force
-package.use.mask
-parent
-profile.bashrc
-use.force
-use.mask
-virtuals
+repos.conf
but I am not sure whether it is necessary to *enforce* that the files
that don't make any sense in the final profile (=/etc/portage/[profile])
actually are ignored when they are present. Instead portage(5) could
document what files should be present in (a) the "final" profile, (b) the
"base" profile, or (c) anywhere in between.
Of course this needs to be thought through in detail but I since this is
the time to do so I thought it can't hurt mentioning this option now.
-- Jonas
Daniel Robbins
>
> To take this even further: why not make even /etc/portage/ itself and
> /etc/make.profile/ support the same files? I think this would simplify
> things quite a bit, and make some of the improvements suggested by Daniel
> unnecessary. E.g. no need to worry whether tail/head terminology makes
> sense or not - instead there is just /etc/portage/parent. That and
> /etc/portage/(make|portage).conf
This is now the solution I am preferring most.
Basically, /etc/portage/profile would have a new location - /etc/portage.
/etc/make.conf moves to /etc/portage/make.defaults (or make.conf as an
alternate name.)
You define your profile(s) in /etc/portage/parent.
This basically collapses everything together in /etc/portage and
eliminates a lot of duplication and confusion.
Good suggestions everyone!
-Daniel
Giuseppe `ferdy` Miceli
>
> To take this even further: why not make even /etc/portage/ itself and
> /etc/make.profile/ support the same files? I think this would
> simplify things quite a bit, and make some of the improvements
> suggested by Daniel unnecessary. E.g. no need to worry whether
> tail/head terminology makes sense or not - instead there is just
> /etc/portage/parent. That and /etc/portage/(make|portage).conf
Daniel> This is now the solution I am preferring most.
Me too. Recursion is bliss.
--
ferdy
ulenrich
effective profile out of many template pieces. A proper algorithm any
Cplus compiler interpolates multi inheritence.
But nevertheless it is hard to interfere as a human. If you want to
play with profile templates you would need some helper tools.
I suggest to use a cleaner and more standard /etc/portage.d scheme:
http://forums.funtoo.org/viewtopic.php?pid=983#p983
Giuseppe `ferdy` Miceli
# It's not bliss. It is the clean way to calculate recursivly the effective
profile out of many template pieces. A proper algorithm any Cplus compiler
interpolates multi inheritence.
Mine was actually supposed to be more a hilarious geeky remark, kind of
"when I get to stumble in iteration and recursion I feel like in heaven" :)
# But nevertheless it is hard to interfere as a human. If you want to play
with profile templates you would need some helper tools.
# I suggest to use a cleaner and more standard /etc/portage.d scheme:
# http://forums.funtoo.org/viewtopic.php?pid=983#p983
In my humble opinion, this schema is really useful with chronological
parsing (like in rc.x directories) where you would like to parse/start
things in a specified chronological order.
Unless I am missing something, in such a specific case we are discussing, I
am under the impression that a recursive approach will allow you to deal
elegantly with the intrinsic inheritance of the profiles.
Cheers,
--