GSoC 2014, Week #7: Going at a fine pace

Hello everyone!

This week has gone pretty well. I took yesterday off to spend the 4th of July with my family and I had some good times, but now is the time that I inform all you lovely readers what was accomplished throughout this week regarding layman.

A word beforehand, my mentor Brian Dolbec (dol-sen) is currently in the hospital and will be there at least until July 13th. I just wanted him to know that my best wishes go out to him and I hope the best for him.

While dol-sen is in the hospital recovering I will be bugging my other mentor (quantumsummers) a lot more than I bet he would hope for because I need the green light on my pull requests I have for certain features that I'll be elaborating more on in this post.

1.) Portage sync module plugin:

    The portage sync module plugin for layman should be ready to be merged with the master git branch. I required more seasoned eyes to skim through it and let me know that it is before merging it. The only change made to it throughout this week was that I added fetching of the remote list to layman by default when running any of the actions in the sync module.

2.) Overlay-maker class:

    This week has included a two changes for the overlay-maker class, one of which was made that directly affect the user.

    1.) The old method of branch tags has been removed:
            I previously added branch support for multiple overlay types.
    In order to declare an overlay had a branch you would simply add the
    <branch></branch> tags to indicate that the overlay uses this "branch".
    This has been changed. When you are creating an overlay.xml file now you
    can specify the branch for multiple source tags. ex.) You have an overlay
    located at http://github.com/twitch153/ebuilds.git and it uses the branch
    experimental, but you have another source of the same repo at
    git://foobar.com/twitch153/repo.git and it uses the branch unofficial. With
    the previous nature of the <branch></branch> xml tag you couldn't
    specify both tags for both sources and you'd be left sad and full of hate
    and anger toward the dev that made the decision to make it such a static
    thing. With the new nature of the branch info though you could do this:

        <source type="git" branch="experimental">http://github.com/twitch153/ebuilds.git</source>
        <source type="git" branch="unofficial">git://foobar.com/twitch153/repo.git</source>

     and that would work perfectly well! Of course, with this new change comes the need to modify the .dtd file again, so I'll have to create a patch and run that by the maintainers of the .dtd file once again. That'll be done once these changes get merged to the master branch.

    2.) Proper feed support was added for the overlay-maker class and
    overlay dictionaries:
        If a user was to run through an interactive overlay maker session and
    specified the feeds to the overlay and wrote the overlay to the file...it
    wouldn't work! Why? Well, it's simple really. The overlay-maker class is an
    interactive session that will create a python dictionary of overlay
    elements. However, due to my clear lack of perfection I used an incorrect
    key for the overlay feeds and therefore the overlay class would totally
    overlook the feeds when creating an overlay object to be written to an
    xml.

3.) Squashfs overlay support:

   For those of you unaware of what squashfs is: it is an archive-like file system. There are absolutely tons of different things about it that I could list but I lack the proper knowledge to continue on by saying anything other than it is like an archiving type similar to tar or zip.  So, in our vast abundance of knowledge we already know that layman already supports tar overlays so is squashfs really all that different? The answer is an emphatic no. It is my own belief that you could probably go even further and say that adding any sort of archive overlay support to layman would be so similar that you might want to make an archive class where all archive overlay types would get their main functions from and go from there based on the little differences that they do have.

    However, this week I added both squashfs overlay support and an external test to see if it works in practice and not just on paper (hint: it does).

Goals for next week:

• Improve on the archive overlay types and possibly make an archive class to centralize the main functions necessary for each type.
• Discuss with quantumsummers about moving some of my work to the master branch.
• Focus on squashing some bugs for layman.

As always, to anyone interested the source code and my commits can be found on git.overlays.gentoo.org/gitweb/[1] or on github.com[2] on layman's gsoc2014 branch.

  [1]http://git.overlays.gentoo.org/gitweb/?p=proj/layman.git;a=shortlog;h=refs/heads/gsoc2014
  [2]https://github.com/twitch153/layman/tree/gsoc2014

With regards,
    Devan Franchini (twitch153)