Mailinglist Archive: opensuse-project (537 mails)

< Previous Next >
[opensuse-project] Fwd: [GSoC Proposal] spec-cleaner
Hi all,
I am writing my proposal here before uploading to the gsoc-melange
portal , please do let me know how i can further refine it:

Title: spec-cleaner redesign to make it modular and easy to extend.

RPM packaging is done using a build recipe , the "spec file". Spec
file authoring has been done for a very long time.
As the distribution moves to newer releases of rpm, the old spec files
(and newer ones) must be checked to make sure they use
newer macros and better spec authoring practices.
The project aims to facilitate this by further improving the
spec-cleaner project with a spec file parser, and an xml based
system (to add more cleaning recipes in the future).

Detailed Description:

The project is a simple spec file checker and cleaner. The code goes
over all available spec files looking for common spec authoring errors
and replaces them
with more readable and correct code.
As opensuse moves to newer versions of rpm, older macros may be
deprecated , some shorthand used in earlier versions of the spec file
may break with newer rpmbuild.
It is not possible to manually look at each spec file and modify them.
This project aims to perform a bunch of the checking and modification
task automatically leaving the packager to look for only subtle
details, there by greatly reducing his/her workload.

Use Cases:
This project will mainly be used by the packagers (actors).
When opensuse moves to newer releases the packagers run the
spec-cleaner through all their spec files.
Spec-cleaner reports any errors along with changes made to files.
The packager can then run tests on the modified spec files to make
sure nothing breaks. He/she then rpmbuilds from the spec-files and
corrects small errors if any to make
the spec file run with newer versions of rpm.

The packager's time looking for common coding errors is greatly reduced.
Specification changes between different version of rpms is taken care
of automatically.

This is an automatic code checker and cleaner. It will not be able to
look for hacks that the packager might have employed to package a
particular software. In some cases it might regard the hack as a bad
coding practice. The packager must look for these manually and apply
necessary corrections.

Technical Details:
The Project would be divided into 3 parts:

Part 1: Read existing code and evaluate how best to modularize it. Run
tests on existing code to make sure the working and the
caveats are well understood.
Part 2: Implement the changes:

Write a spec file parser

Having done a preliminary search for spec file parsers , i
have not found any.
I have looked at python-rpm and its more of a package to
work with rpm packages than spec files, so there arises a need for
a generic spec file parser.
python-rpm and rpm in general contains a specific module
called "rpmSpecParse()" which could be isolated and used as a
parser for the cleaner, this needs further looking into.

Come up with a XML schema which is easy to understand and
easy to extend.

Adding new clean-up recipes is not very semantically
organized. A simple XML file wrapping new cleaning recipes in
appropriate tags would be more appropriate.
The rough markup could be ,

                                               <rpm version>

<macro affected>



                     <replace with>

                     </replace with>

</macro affected>
                                               </rpm version>

Move portions of current spec-cleaner code that are hard
coded , into separate configuration files so that they can be
modified without touching the code and also have more
semantically organized.

Part 3:
Extend available test cases and write a more if time permits.
Write documentation / augment the code written with doxygen headers.

Why me:
I have used python extensively in my projects (reference )
also i am working on converting IPS (opensolaris) binary packages to
RPM, for (here we use rpm5)
so i have a fair understanding of how the spec file is authored and
what are the available macros etc.
Also , from past projects i have worked on. I have learnt (the hardway
:( ) that "shipping" of the project must be a feature and
i will follow the same in the current spec-cleaner project and all
future projects.
Contact Information:

IRC nick: gancient  (on most irc channels , freenode ,oftc)
email: kunal.t2@xxxxxxxxx
IM : kunal.t2 (on gtalk)

Kunal Ghosh
Dept of Computer Sc. & Engineering.


Kunal Ghosh
Dept of Computer Sc. & Engineering.

To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >
This Thread
  • No further messages