propozition of specs cleanups

[Tomasz Kłoczko]

Dnia 03-02-2006, pią o godzinie 05:27 -0500, Mike A. Harris napisał(a):
[..]
> While that cleans up a line that might be currently unused, it
> doesn't have any real functional change, and some packages might
> include that as a reminder to fill in the documentation in a future
> package update.  For example, when I'm creating new rpms, sometimes
> I am in a hurry to get a useable package out the door and into
> rawhide ASAP, but there's no reason to make the package 100% perfect,
> so I generate a spec from a template I use, and fill in the missing
> pieces over time.

I'm working on variouse rpm packages more than nine years (I supose this
is more than two time or longer than you; still you can find many my
packages in RH contrib).

Your recent xorg* packages are very *badly* written (sorry but it looks
for me like this your first bigger work on maintaining spec files .. or
as you don't know for what can be used awk/sed/perl ;>).
All ot them have many lines which are can be dropped without removing
single usable functionality but which allow meke spec files more
readable like stupid comments (probaly placing comments was take more
time than verify all this %doc), placing in %fiels %{_bindir},
%{_mandir} and similar ad %dir .. THIS directories are in filesystem,
%{_datadir}/aclocal which belongs to autoconf ... many, many simillar
things :>.

Do you wan't more sed lines ? :)

Look .. most of empty %doc are in xorg* so please don't try defent this
as reminder or so .. you metodology for me shows as bad it is :>
Trust me .. by this you spend on this much more time than it requires.
And probably some %doc reminder will be never removed because you will
have each time much more importand things.
Quality of package/spec file as same as .c file strongly depends on
first impmentation.

Most of this kind "bugs" can be fixed using single sed line.
Again: do you wan't more sed lines ? :)

> This is one thing I find useful when editing a package, that says
> to me "Mike, you put an empty %doc, which means you have not yet
> investigated the package closely to see if there is something that
> should be in %doc.  Please do that at some point."  That's fairly
> useful. ;o)

Verry usefull .. for start look on you as bad developer ;>
Sorry ..

> > - replace .gz suffix by * from %{_mandir}/* entries
> >   This allow choose on build stage generate binary packages with or
> >   without gzipped man pages.
> 
> Yep, that is general good RPM housekeeping.  I think the best thing
> to do, is to have some global rpmlint-like tests run in our buildsystem
> that look for these types of uglyisms, and force them to be fixed in
> order for the package to build.  (pre-tests)
> 
> While it would have some value, and could be enhanced over time with
> other tests, it'd also likely be low priority overall compared to
> other work that needs doing..
> 
> Best thing for people to do, is to generate patches and submit them
> to bugzilla for now.

Please don't be crazy ;>
Diffstat for submitted chages:
[devel]$ cvs diff -u | diffstat .diff | tail -n 1
 86 files changed, 225 insertions(+), 280 deletions(-)
 ^^

few seconds on thinkig on sed line you want "convert" to few hours
sitting on bugzilla which will generate next few hours/person for
closing and commiting all this very simple/elementar changes.
Plain stupidity :>

I'm mailing to this list for introduce this in cvs tree in possible
shorter time frame .. please don't say me "go to /dev/bugzilla^Wtree or
and try game with your balls" .. ;>)
Commiting this do not require immediate rebuilding each 86 packages.

kloczek