I like Linux Mint. The only thing which I was missing was command line version of mintUpdate, so I decided to write one.
First I started to analyze existing version of mintUpdate (in version 17.1 “Rebecca”) and then I “converted” it into CLI version.
So here it is – brand new mintUpdateCLI.py – I placed it on github where you can DOWNLOAD it. Please take it as proof of concept, it has a version number 0.1 and I wanted to try if I can write it at all. I tried to implement all the functions GUI version has and I tried to do it with minimal number of changes to the original code (I took slightly more relaxed approach at the end). It is a pitty mintUpdate does not have it’s algorithms in separate library, to create mintUpdateCLI would be much faster and easier, but it wasn’t as bad at the end considering I managed to do it in several weeks in my free time only.
Also before I show you how to use it, let me explain about updates. Linux Mint updater (mintUpdate.py) groups packages into groups. Grouped updates are called just “updates” but I introduced term “package group” so it is more clear what kind of update it is – if it is single package update or group update which may include one or more single packages.
Usage is simple – download it, change permissions so it is executable and run it.
basic usage is:
mintUpdateCLI.py list – lists package groups for update
– updates all packages available (as per levels specified)
mintUpdateCLI.py install packagegroup1 packagegroup2 ... – installs only specified package groups
If you do not specify any arguments, help with all options is displayed. I will post some screenshots as well.
It will ask for user password whenever it needs it. It also uses apt-get instead of synaptic (as it is CLI version). I was also surprised to find out apt-get does not support the list of packages to be installed in form of a file – command line is the only option. Luckily Linux Mint command line limit is huge – 262144 bytes (it can be checked by
getconf ARG_MAX) and it can be adjusted as kernel parameter if needed.
In my view consolidation of mintUpdate and mintUpdateCLI is a phase 2, where common shared library containing only algorithms is more than desired. Otherwise if any bugs are fixed/new logic is introduced it would have to be changed twice – once for GUI, second time for CLI part. Also I left interaction between CLI and GUI versions open – for example once the system is updated via CLI part, it could send for example sighup to the GUI part so it performs refresh (or performs refresh at the time user interacts with it again).
I’m looking forward for feedback.
Whilst working on it, I found several Linux and programming anti-patterns.
The first anti-pattern is that there was no CLI version of mintUpdate. In my view every GUI basic component should have CLI equivalent – that’s one of the things which makes Linux different from Windows right? I feel I can allow myself this small rant as I’m actually fixing this by providing CLI version. By the way – NetworkManager started in the same way…
Other anti-patterns regarding mintUpdate are related to programming. I was surprised to find out how are data, algorithms and gtk code mixed together. Another surprise was related to logging. I found nice example describing python logging here. Luckily we live in open-source World, so this can be fixed as well