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.

Abstract: 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 extension system (to add more cleaning recipes in the future).

Detailed Description:

Background: 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.

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

Caveats: 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 ,

<recipe>                                                <rpm version>

<macro affected>

<regexp>

</regexp>

<replace with>

</replace with>

</macro affected>                                                </rpm version>                                     </recipe>

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 https://github.com/face-rec-mvit/Code_PyRec%C2%A0) also i am working on converting IPS (opensolaris) binary packages to RPM, for belenix.org (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@gmail.com IM : kunal.t2 (on gtalk)

-- regards ------- Kunal Ghosh Dept of Computer Sc. & Engineering. Sir MVIT Bangalore,India

permalink: member.acm.org/~kunal.t2 Blog:kunalghosh.wordpress.com Website:www.kunalghosh.net46.net

-- regards ------- Kunal Ghosh Dept of Computer Sc. & Engineering. Sir MVIT Bangalore,India

permalink: member.acm.org/~kunal.t2 Blog:kunalghosh.wordpress.com Website:www.kunalghosh.net46.net