GSoC 2014, Week #6: Hit the mid point

You know, they say that the point of no return is when you've gone so far that turning back just seems impossible.

Typically that sounds pretty dismal. But in this case it's the exact opposite!

This week has been a week of good fortune for me and this is why:

1.) I passed my GSoC midterm evaluations! Which means we've hit the midpoint for the GSoC program.

2.) My main computer is alive again! My computer (a.k.a Buff-Kitty) is finally alive after me destroying tons of computer parts (I don't want to talk about it...). It's been awhile but I can confidently say you were missed, Buff-Kitty.

In celebration of new life, a lolcat shall be posted:

You sure do, Buff-Kitty. You sure do.

Enough of that though. Onto the goodies of the week. So what's new?

Recall what I said my plans for this week were:

• Revamp the overlay definition generator script.
• Polish up the portage sync module.
• Begin adding squashfs overlay support. 

 So what was accomplished this week? To all of you who were ecstatic about having squashfs overlay support well I have good news for you. The good news is that you'll get it...eventually. But not this week. Because I was being doing a complete overhaul on the overlay definition generator script and polishing up the portage sync module to add some nifty new features to it.

Let's start with the sync plugin module since it didn't get an entirely new overhaul.

 1.) Portage Sync Module:

  Recall in my previous post how I explained that the sync module made use of two variable methods of running: the API method, and the subprocess method. By default, the sync plugin should run via the API method, however, if something occurs that prevents this from happening then portage will fall back on the subprocess method. Although to be honest with you I don't know what could happen to prevent you from running a program's API yet, still be able to run the subprocess. That's an aside though.

  "Okay, I remember all of this and I remember that it interacts via a file in your repos.conf folder, big deal, what's new?" Nice to see you're just as impatient as I am. So I'll just cut to the chase. You can tell portage to sync a repo that doesn't exist. Just because the repo is listed in the repos.conf config file it doesn't necessarily mean that the repository is installed. This would cause a failure to sync the repo (for obvious reasons).

  Fear not! For a new feature to the API variant of the plugin has been added. This feature will check the configuration for the repository in the repos.conf config file and create a new overlay definition using the newly revamped overlay-maker class. After creating the new overlay definition.xml file it will then install the new repo for you. Then when you go to sync the repo again, it will successfully sync the repo (for obvious reasons).

2.) Overlay-Maker class:

  Previously this was just a simple script to prompt users for overlay information and then to pipe it into a script. Throughout this week that has changed and the overlay-maker has been turned into a little more than that. By making use of the new overlay-maker class you can make layman overlay definitions and write them to a desired file via a script, or an interactive command line interface. Further more the overlay-maker adds auto-completion support for overlays that have mirrors from github.com or from git.overlays.gentoo.org.

  If given a source URL that is from either of those two locations the script will automatically fill out the rest of the available sources for that overlay along with the homepage and feeds available.

  It is possible that before the end of this GSoC that the overlay-maker will be able to be ran through an array of subparser commands from layman, however even if I am not able to get it accomplished prior to the end of the program, I do hope to get it done so that users can add overlay definitions simply by doing something like:

    layman repo --add twitch153

  This would then bring up the interactive interface to add the overlay by the name of twitch153 and add it to a file of your choice. It would also make it easier for developers maintaining large repository.xml files. If they wanted to complete remove a repo from a large repository.xml file and this method of interaction was possible they could run:

    layman repo --location=repository.xml --del twitch153

  And have the peace of mind of knowing it is gone for good. The other positive aspect of this is that you could then create a script or a cron to add/remove repos from a .xml file. The possibilities are exciting for sure.

  For all of you layman users, during this upcoming week or weekend a new release candidate for layman is going to the portage tree and will be available for all to install and test. So enjoy that and I encourage feedback about it including things you would like to see in the next RC of layman (because there will be another one before the end of this GSoC...hint, hint).

Goals for next week:

• Add finishing touches to portage sync module.
• Continue to work on overlay-maker class.
• Hopefully begin adding squashfs overlay support.

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

Hope everyone is enjoying their summers!

With regards,
    Devan Franchini (twitch153)