This week has been good in making leeway with open bugs for layman!
To all of you who are unaware of what bugs are (no, not the squirmy wormy ones), a bug is essentially a report regarding a certain program or package or pretty much whatever. It can cover a vast amount of things.
If you are curious to see the open bug for layman, follow this link here:
https://bugs.gentoo.org/buglist.cgi?quicksearch=layman&list_id=2406998
But I'm getting ahead of myself, I'm going to begin by discussing what has been accomplished this week for layman.
1.) Centralize archive overlay type code:
Last week I added support for squashfs overlay types for layman and it struck me: "Hrm, the code for both tar overlays and squashfs overlays are super similar. So similar, in fact that the differences are less than the similarities. I bet I could make a class that all archive types get their main functions from". So that's exactly what I did!I created the ArchiveOverlay class which took all the similar code from both archive overlay types and brought it together for any archive overlay type to grab from. It's like a goody bag of archive functions.
So now any archive overlay type will now subclass from the ArchiveOverlay instead of the SourceOverlay class, which the ArchiveOverlay class subclasses from. It's a large hierarchy that is as follows:
<archive overlay type being installed>
|
Overlay
|
<archive overlay type>
|
ArchiveOverlay
|
SourceOverlay
|
Overlay installed
|
???
|
Profit!
When you go to install a tar overlay layman will know it is a tar overlay type. The Overlay class will then call the class associated with that type, being tar. The class associate with tar is...TarOverlay! So the TarOverlay class is called, and it wants to call the add() function. However, if you looked at the source code you'd see that the TarOverlay class doesn't have an add() function. So where does it get it from? The ArchiveOverlay class that it subclasses.
The ArchiveOverlay class requires you to extract the archive, that the TarOverlay class has in its own class, that's what makes this class different from say...the SquashfsOverlay class. The way you extract the archive is different.
So the TarOverlay class will call the ArchiveOverlay class' add() function which in turn will make use of the TarOverlay class' extract() function. The ArchiveOverlay class' add() function isn't complete though, it will make use of the add() function in the SourceOverlay class, to do anything else that the ArchiveOverlay class' function didn't cover. After this is complete you can enjoy your newly installed archive overlay and feel happy that you didn't have to do anything more than: layman -a <overlay>
2.) Adding multiple description field support:
If you look at this bug report here: https://bugs.gentoo.org/show_bug.cgi?id=465730 you will see that layman currently did not handle multiple description fields when there was the possibility to do so (mostly due to it being translated into different languages and whatnot). This week I added that support to the Overlay class.I personally believe it needs to be fine-tuned in a few ways. I think I will wait until dol-sen's recovery to fully tackle this bug though. In all honesty it would work fine now as it is, but would not take into account that lang attribute of the description xml tag.
In accordance with the changes being made to the Overlay class to support multiple description fields, the layman sync plugin and the overlay-maker class both also have been modified to reflect the newly added support. The overlay-maker class does not currently add more than one description to the overlay being created though. A function has been added to grab the description though and can be used to prompt the user for multiple description fields if we decide that would best.
3.) Slight additions to overlay-maker class:
A few changes have been made to the overlay-maker class.- github,com and git.overlays.gentoo.org https:// URLs are now supported (why they weren't before, I have no idea...I blame the media).
- On a successful write, the user is now notified of where the xml file is being written to.
4.) Adds interactive session for unofficial overlay installs:
https://bugs.gentoo.org/show_bug.cgi?id=315359 hoped to add more of a warning to users that are not installing official overlays. I added that feature which I also made configurable. So now a user will be prompted when installing unofficial layman overlays. They will be asked if they would like to continue even though the overlay is unofficial and if they respond with "yes" then they will continue on with the installation.This feature, as I said previously, will be configurable and will be able to be turned on or off with the "check_official" configuration option. The config option name might be changed in the near future and if it does you guys will be the first to know. Well, unless someone checks the source code and it's on there before I report it to you.
5.) CLI improvements:
CLI or (command-line interface) is the method of calling a command through the command-line and give it certain command line arguments. You've seen this in layman -a <overlay> the command line arguments here are the -a flag and the <overlay> name.Keeping that in mind, know that if you previously wanted to install multiple layman overlays, you'd have to do it as so: layman -a <overlay 1> -a <overlay 2>. But to be honest that's not really a natural way of doing so. Over this week I changed the way layman handled certain actions such as --add or --delete. So now instead of having to call the flag multiple times you can simply append multiple overlay names to the actions, as so: layman -a <overlay 1> <overlay 2>.
This was done by removing the action parameter of the argparser add_argument function, and replacing it with nargs = '+'. Doing this changes the behaviour of how the flag gathers its information and will allow users to perform layman actions in a more natural manner.
Another minimal change has been made to the command line arguments as well. I have taken the liberty of renaming the --setup_help flag to --setup-help as it should have been originally. Whether I made this mistake or not, I'm not aware. But it's fixed now, which is good.
6.) Ability to enable or disable overlays:
Imagine you're spending the night in a hotel that just so happens to have really crappy internet (it's not like they don't have multiple people using the internet all the time, all day long or anything...) and you want to prevent portage from accessing the ebuilds that a certain overlay has installed.So how would you tackle this problem? You could go ahead and delete the overlay. That would work, sure. Unfortunately, you'd have to download the overlay again after that's done. Which, given your current situation, would suck. Or you could just have portage "forget" the overlay exists.
How? With layman's new ability to disable and then enable the overlay. Preface: this currently only works if you use the make.conf repo configuration method.
If you were to look in your make.conf (located by default) in /var/lib/layman, you would see the following:
PORTDIR_OVERLAY="
<overlay locations>
$PORTDIR_OVERLAY
"
ENABLED="
<overlay 1 location>
<overlay 2 location>
"
DISABLED="
"
PORTDIR_OVERLAY="
$ENABLED
$PORTDIR_OVERLAY
"
So now, portage will only acknowledge the overlays listed in the ENABLED var and ignore the overlays in the DISABLED var. When calling layman -D <overlay 1> the overlay location of <overlay 1> will then be moved to the DISABLED var in the make.conf. Which you can re-enabled by invoking the layman -E <overlay 1> command. I hope to incorporate this into the repos.conf repo configuration method as well but how layman should go about doing so needs to be discussed.
7.) Small fixes made to codebase:
Two small fixes were made to layman's codebase.
- Improvements of the way layman handled the success or failure of a write to a repo config method has been fixed. layman will now take into account the fact that a user can be invoking more than one repo config method and one may fail while the other succeeds. Previously this would lead to a false positive. That behaviour has been fixed.
- layman previously falsely informed a user that an overlay was not supported if they ran layman -v -i <overlay> and the overlay was actually supported. This was because layman was unpacking the values from the Info() function and unpacked the boolean for "supported" in the position of the boolean for "official".
- Begin working on migrating docstring tests to a full test suite.
- This goal has been allotted to take 2 weeks so don't expect a massively fulfilling report next week.
[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)
No comments:
Post a Comment