Hi -
> > In order to support file/rpm archives that are organized via symlink
> > trees, add an "-L" option to debuginfod, meaning about the same as for
> > find(1) or ls(1): to traverse rather than ignore symlinks.
>
> Could you give an example of when exactly this is necessary?
Because some file/rpm archievs are organized via symlink trees. :-)
For example, a build system may have
/packages/N/V/R/ARCH/*.rpm files, which are a legion
plus /compose/F30/SPIN/ARCH/ directories, which contain
symlinks into the former
or package archives stored over multiple NFS mounts, whose
contents are interleaved via symlinks.
> I assume that it isn't really necessary for rpm archives, you probably
> don't want to follow any symlinks from an archive that point to
> something outside the archive, and you will see all files in the
> archive anyway. So following symlinks doesn't seem helpful there.
These are not symlinks WITHIN rpms. These are symlinks encountered
during filesystem traversal looking for RPMs.
> Also why combine symlink following with cross-device searches?
> Shouldn't that be separate options?
They could be. They seemed to go well together in the cases I've seen
and thought about. Would you like another option now?
> > -########################################################################
> > -
> > -# Ensure debuginfod-find can be safely called with no arguments.
> > -# Use a relative path to prevent automatic line breaks in the output
> > -# due to excessive characters.
> > -testrun_compare ../../debuginfod/debuginfod-find <<EOF
> > -Usage: ../../debuginfod/debuginfod-find debuginfo BUILDID
> > - or: ../../debuginfod/debuginfod-find executable BUILDID
> > - or: ../../debuginfod/debuginfod-find source BUILDID /FILENAME
> > -EOF
> > -
>
> This wasn't a very useful test, but did you really intend to remove it?
Yes, as more options are added to that tool, the test case is going to
be obsoleted every time. This hunk belongs with the
interruptibility/progress patch more, I guess.
- FChE
