[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: propozition of specs cleanups

Tomasz Kłoczko wrote:

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.

You might have a point but this is pretty rude way to express it. --- Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]