Re: [gentoo-portage-dev] Re: Bugzilla Bug 112779: New and Improved Way to Handle /etc/portage

[Zac Medico]

Brian Harring wrote:
> This makes portage go looking in two different locations for
> overrides; I know from looking through the code,
> /etc/portage/package.* overrides the includes, but users won't.

This behavior could be documented and possibly configurable.

>
> Configuration in two seperate locations of the same thing is usually a
> bad idea (exempting global configuration, user configuration, which
> this is not).  It's not intuitive, mainly.
>

The idea behind my patch was something akin to /etc/env.d, where it's easy to yank things in and out in groups.  That makes it easy for tools (unmasking and what else?) to make "transactional" changes, in a sense.

> I'd argue for extending the existing files syntax rather then this
> tbh, tag in a source command makes a bit more sense to me.
>
> Plus side, with a source command, you just comment it out and you've
> disabled that import.  With your solution, have to remove the file
> from the directory.
>

Rather than remove a directory, you could simpley move it into another directory (easy for tools to handle).

>
>
>>Index: pym/portage_util.py
>>===================================================================
>>--- pym/portage_util.py	(revision 2314)
>>+++ pym/portage_util.py	(working copy)
>>@@ -463,3 +463,12 @@
>> 		writemsg(line, noiselevel=1)
>> 	writemsg("Please file a bug for %s\n" % sys.argv[0], noiselevel=1)
>> 	writemsg("====================================\n\n", noiselevel=1)
>>+
>>+def subdir_paths(parent):
>>+	full_paths=[]
>>+	if os.path.exists(parent) and os.path.isdir(parent):
>>+		for x in os.listdir(parent):
>>+			full_path=os.path.join(parent,x)
>>+			if os.path.isdir(full_path):
>>+				full_paths.append(full_path)
>>+	return full_paths
>
>
> Why the additional function when filter/for loop + listdir handles
> this already?  You're sidestepping the stat caching via this, which
> potentially isn't a horrid thing (don't like (cache|list)dir
> personally), but it seems unintended.
>
> Additionally...
> mkdir d && ln -s d d2 && python -c'import os;print os.path.isdir("d2")'
>
> os.path.isdir doesn't discern between symlinks targetting a dir, and a
> dir, so
> mkdir -p a/b/ && ln -sf ../../ a/b/c
>
> Will induce a cycle, and this code will shoot right on through till
> either it hits a sys limit (path length), or runs out of memory.
>

Good points.  I have to admit that I did not put much thought into that function.  Like Jason said, the paths should be sorted.  It certainly needs improvement. :)

Zac
-- 
gentoo-portage-dev@g.o mailing list