Differences between revisions 3 and 4
Revision 3 as of 2013-04-21 15:30:36
Size: 7673
Editor: ?EmmanouilKiagias
Comment:
Revision 4 as of 2013-04-21 15:45:30
Size: 7667
Editor: ?EmmanouilKiagias
Comment:
Deletions are marked like this. Additions are marked like this.
Line 30: Line 30:
 * '''Exams and other commitments''': I have exams during June 6-June 22, but then I can start after at June 17 since I have very few things to study for my exams.  * '''Exams and other commitments''': I have exams during June 6-June 22, but then I can start at June 17 since I have very few things to study for my exams.
  • Name Emmanouil Kiagias

  • Contact/Email: e.kiagias@gmail.com, ala_mages irc-freenode

  • Background: I am a 5th year undergraduate CS student at Athens University of Economics and Business (Greece). I have worked at CERN, as a technical student, from March 2012 to April 2013. I was a member of the LHCb computing group in Physics Department. My project was to implement a set of profiling tools which collect data from simulations in an abstract and generic way and also provide a framework to deploy modules for analysis on the collected data through a web interface. Is was written in Python, Oracle sql and included a lot of scripting. My working environment was slc6 (scientific linux cern 6). I am also familiar with Java and C++ due to different projects, in topics such as artificial intelligence, networking and databases, in the course of my university studies.

  • What makes you the best person to work on this project? During my stay at CERN I was integrated in an international and scientific environment where I learned to work both independently and as a part of a team on production level. Thus, I became very familiar with both Python and SQL which are the needed skills for implementing of the GsoC project. Also, being an active member of my university's F.O.S.S community, I enjoy working on open source projects, learn new things and improve my skills as a programmer.

  • Project title Redesign metapackage creation for Debian Blends

  • Project details: In Debian Blends a basic way to install packages belonging to a certain user task is a set of so called metapackages. The package blends-dev is responsible for creating these metapackages taking as input data task files, which specify dependecies from binary packages. blends-dev creates a source package which has set all the dependencies, according to the specification inside the task files, by validating these dependencies against the packages inside the package pool. This ensures that the resulting metapackages will be installed nicely into a system that is up to date at the time of creation of this source package. Currently blends-dev is verifying the package pool of the architecture on which the source package is created (when blends-dev is called). In practice this has the effect that the most popular architectures (i386, amd64) are used as reference for metapackages which are intended to work on all available Debian architectures. Strictly speaking this is wrong even if there is no known case were this has leaded to practical problem. The task of the GSoC project is to rewrite the blends-dev code to enable architecture dependent metapackages. The new blends-dev design will use the UltimateDebianDatabase (UDD) to obtain the needed information instead of using information from the system where blends-dev is called. The UDD is a commonly used resource in Blends and provides a very handy access to the necessary information about binary packages. By querying specific information from the UDD, it will be possible to create a package pool for a desired architecture, to be provided to blends-dev along with the task files. Additionally, because metapackages are generated depending on the content of the package pool, the resulting source package for the latest (or any) release could be different from a previous version simply because packages were added (or removed) from the package pool. Currently these changes are not reflected inside Blends' changelog. So in addition the new blends-dev will provide a way to store the dependencies status for all Blends releases in order to keep track of added and removed packages between versions. The new implementation will be coded from scratch using Python.

  • An optional goal of this project would be to investigate the possibility of using Debtags in blends-dev. Either use them by themselves or in combination with the task files when creating metapackages.

  • Synopsis: The new blends-dev implementation will provide Blends, architecture dependent, metapackage creation and a way to store the dependencies status for all Blends releases.

  • Benefits to Debian: Metapackages will be created based on all of the supported architectures and not only i386 and amd64 thus avoiding potential practical problems, new metapackages will illustrate the differences in dependencies between Blends' versions.

  • Deliverables: An automated procedure to create Blends metapackages for all supported architectures.

  • Project schedule (prososal):

  • Community bonding period (May 27 - June 16)

  • → Get to know my mentor better
  • → Read documentation in detail regarding blends-dev, the UltimateDebianDatabase (UDD) in order to obtain a complete understanding of how the existing code works.

  • → Set up my own UDD instance, do some basic information retrieval from it in order to get more familiar with the database's structure.
  • June 17 - July 7 (3 weeks)

  • → Currently blends-dev is using the apt-cache dump (with custom options) output to create a package pool to validate the dependencies. So the first step is to write a set of UDD sql queries which will get the information about all the available packages of a desired architecture (similar to apt-cache dump output) in a uniform and easy-to-manage way. Write methods to parse and manage the UDD output and create a package pool. Then test, compare the existing code's package pool with the new package pool created from UDD.

  • July 8 - July 21 (2 weeks)

  • → Write methods to parse the input task files and any other needed methods to imitate the existing blends-dev functionality.

  • July 22 - August 11 (3 weeks)

  • → Connect the udd and input parsing parts together, debug and write a procedure to create metapackages with this new implementation.
  • August 12 - August 25 (2 weeks)

  • → Test and confirm that metapackages created with the new design are valid.
  • August 26 - September 8 (2 weeks)

  • → Write methods to store the dependencies for all the versions of Blends (keep track of the added/removed packages across releases). First approach will be a small json database, other approaches may come while programming.
  • September 9 - September 16 (1 week)

  • → Write documentation and clean up code making final tweaks.
  • The aforementioned dates may change depending on the circumstances (some parts may take less time than mentioned), I will try to finish up earlier so I can also work for the optional goal of the project.
  • Exams and other commitments: I have exams during June 6-June 22, but then I can start at June 17 since I have very few things to study for my exams.

  • Other summer plans: No, I do not have any other summer plans. Working for an open source project during summer it's a great plan itself.

  • Why Debian?: I started using Debian 3 years ago and this distribution was the one that kept me to linux. Open source software in general has been really influential in the development of my knowledge and skills as a programmer. I feel this summer through GsoC it can be a great opportunity for me to contribute and actively be part to this community. After using what Debian provides in my everyday work and life I would love to take part in it as an active developer.

  • No, I am not applying for other projects in SoC.