Bug 146821

Description of problem:
If you try to use the --fileorder option of genhdlist and some of 
the rpms you had pkgorder scan hand file names longer than 79 
characters, then the behavior of genhdlist is non-deterministic.
Depending on the length of the package names it may fail outright, 
generate a "halfway" sorted package list, or something that is just
wrong.  If your lucky it will actually fail the sanity check on the
filename, if not it will not "fail" and you won't find out anythings
wrong until you install the generated media on a system and things 
get installed in a very wrong order (or worse, almost right order).

Version-Release number of selected component (if applicable):
9.1.4.1

How reproducible:
Always (though the extent of the damage is variable)

Steps to Reproduce:
1. In a valid rpm repository preped for building anaconda media
   add a couple rpms whose names are longer than 79 characters.
2. Now run genhdlist, pkgorder, and genhdlist with the proper options
   as you would when building the media.

  
Actual results:
Depends on your package names (things with lots of -'s in the name
will pass the sanity test).  Either it fails the filename sanity, or
you end up with packages sorted wrong.

Expected results:
No problems whatsoever.

Additional info:
The problem is trivial.  Though pkgorder does not care about the size 
of the lines it prints genhdlist creates a static buffer of 80 chars,
and one must be used for \0.  Just need to change it to dynamically
allocate its buffer as needed.  I have a patch for this and will 
attach it.

BTW, if you follow the earlier Fedora notes on building kernel 
modules in seperate rpms, you end up with some really long filenames 
for the kernel module rpms (kernel-module-somemod-%(uname -r)-1-
1.rpm, increase the length of the original kernel release and the 
kernel modules release, and, hypothetically speaking of course, you 
will exceed 79 chars).