Re: [PATCH] package_rpm.bbclass: support packaging of symlinks to directories

[Patrick Ohly <patrick.ohly@intel.com>]

On Wed, 2015-02-18 at 09:43 +0100, Patrick Ohly wrote:
> On Tue, 2015-02-17 at 08:55 -0700, Christopher Larson wrote:
> > 
> > On Tue, Feb 17, 2015 at 6:42 AM, Patrick Ohly <patrick.ohly@intel.com>
> > wrote:
> >         +            # Treat all symlinks to directories as normal
> >         files.
> >         +            # os.walk() lists them as directories.
> >         +            for i, entry in enumerate(dirs):
> >         +                if os.path.islink(os.path.join(rootpath,
> >         entry)):
> >         +                    del dirs[i]
> >         +                    files.append(entry)
> >         +
> > 
> > You're deleting elements of a list while you're iterating over it. I'm
> > fairly certain that will lead to pain, unless you explicitly ensure
> > you're operating against a copy: for i, entry in
> > enumerate(list(dirs)):
> 
> I was wondering about that myself, but couldn't find any definite
> statement about whether it's okay or not for enumerate(). It works in
> practice, but of course that doesn't guarantee that it is okay.

The enumerate() documentation says that it is equivalent to a "for in"
loop, and documentation for that says "it is *recommended* that you
first make a copy" (emphasis mine). IMHO it means the behavior is simply
undefined.

> Iterating backwards will be more obviously correct, I'll send a patch
> update using that.

The recommended approach is using a slice copy
(https://docs.python.org/2/tutorial/controlflow.html#for-statements), so
how about this:

# Avoid modifying the list we iterate over, iterate over slice copy
# instead.
for i, entry in enumerate(dirs[:]):
    if os.path.islink(os.path.join(rootpath, entry)):
         del dirs[i]
         files.append(entry)

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.