patchify
========

The point of this script is to look for those packages that use the files
config.sub and/or config.guess from the autoconf tools, and do not have the
latest versions that include knowledge of aarch64.

For now, this only works with Fedora and rpm-based packages; it relies
heavily on the spec files being correct and usable.

Running the script
==================
The script -- patchify -- reads stdin for a list of directories.  It
makes the assumption that each directory is a result of a 'fedpkg clone'
for that package.  When I run this in a directory full of these kinds of
directories, I do it this way:

   $ ls -d * | ./patchify 2>&1 | tee run.log

It is a bit on the chatty side.  When done, it will print a summary of
what was found.  Further, as it sorts through the packages, it makes lists
of package names based on what it finds and writes them out.  The lists
are named *.pkgs and the contents are:

   * autoconf.pkgs -- these packages all use autoconf or autoreconf or
     autogen.sh in the %prep or %build sections of their spec file.

   * autoreconf.pkgs -- these use autoreconf in the %prep or %build
     sections of their spec file, but they also use --install or --force
     and they do not use autoreconf if block.  If these conditions are
     all true, the package will take care of itself on next build.

   * configure.pkgs -- these packages use %configure or ./configure in
     the %prep or %build sections of their spec file.  They may or may
     not use config.{sub.guess}.

   * other.pkgs -- these packages do not use any of the autoconf or
     ./configure variations listed above.

   * deadpkg.pkgs -- there was a notice in the package directory that
     the package is now dead.

   * unpackfail.pkgs -- for some reason, a 'fedpkg prep' fails for these
     packages.

   * nospec.pkgs -- the heuristics for finding the spec file failed
     so the assumption is that there is none.

   * nosourcedir.pkgs -- the heuristics for finding the directory of
     unpacked source failed for some reason.

   * clonefail.pkgs -- when preparing an aarch64 patch, the source
     directory of the package is copied so that a diff can be done
     later; packages in this list had that copy fail for some reason.

   * findfail.pkgs -- after the source has been unpacked, a 'find' is
     run to look for config.{sub,guess}; packages in this list had
     that find command fail for unexpected reasons.

   * overwritefail.pkgs -- an attempt was made to replace config.{sub,guess}
     in a copy of the source tree and that attempt failed, preventing a
     patch from being made.

   * noconfig.pkgs -- the packages in this list use some form of ./configure
     but they do not have a config.{sub,guess} file being used.

   * nopatch.pkgs -- the packages in this list use some form of ./configure
     but do not need to be patched for aarch64 (i.e., aarch64 was included
     in their config.{sub,guess} files).

   * patched.pkgs -- the packages in this list use some form of ./configure
     and have one or both of config.{sub,guess} that do not provide for
     aarch64, so a patch has been generated for them.  Suppose a package
     is named 'foo', version 4.1, and the result of 'fedpkg clone foo' is
     in the directory 'foo' with it's source in 'foo/foo-4.1'.  A package
     in this file will now also have a directory 'foo/foo-4.1-aarch64'
     with the necessary config.{sub,guess} changes, and a new patch file
     and a modified spec file that includes the new patch file.

   * error.pkgs -- this is the list of packages that had some other sort
     of error not otherwise captured during the process of getting the
     latest source, unpacking it, looking for ./configure and such, then
     preparing a patch, if needed.