Hi all
In a previous patchset extra metadata was added to paks. The intention of this patchset was to make use of this metadata in pakfire and services.cgi. Along the road it was noted by Michael and Jonatan that there was a lot of duplicate and/or ugly code going on there that should be improved and not duplicated once more.
I have been working on this for quite some time, seperating logic and UI to have more generic functions in pakfire that can be reused more avoiding duplicate code in pakfire and other scripts that need data from pakfire. Here and there I also added other improvements as the cleaner code made those easy to implement.
I hope I have split the changes in small enough patches to make them easier to test.
- Patch 1: The function Pakfire::dblist is used to get a list of all paks but, until now, printed this list as a user formatted text which then needed to be catched and parsed again or parts of its code was duplicated to directly parse the .db files. This patch removes all UI parts from the function and refactors it to return the pak list as a hash instead of printing it as text. Also removed the core upgrade check and output from that function and added a function Pakfire::coredbinfo which returns available core db data as a hash. While moving the UI parts to the places where dblist is called I also added a bit more verbosity to the 'pakfire list' command by - adding an 'Installed: yes/no' field, so that also without color output this info is available. And - when a package upgrade is available it will now also be displayed. Example output of pakfire list: --- ...
Name: wio ProgVersion: 1.3.2 Release: 14 Installed: yes
Name: xinetd ProgVersion: 2.3.15 Release: 2 Installed: no
Name: zabbix_agentd ProgVersion: 4.2.6 Release: 4 Installed: yes Update available: Version: 4.2.6 -> 5.0.21 Release: 4 -> 5
204 packages total. --- And finaly I added the currently installed version to each installed pak in pakfire.cgi as that info is now available there.
- Patch 2: The result of previous patch are 2 'library' functions which are now the go-to functions if you need data from the core-list.db or packages_list.db files. Those files should not be parsed manually anymore anywhere else. This patch replaces such manual parsing in the 'pakfire install' routine.
- Patch 3: Does the same in the Pakfire::dbgetlist function. Also in this function functionality already in Pakfire::getmetafile was duplicated. This was also replaced by a call to getmetafile.
- Patch 4: Parsing of core-list.db in Pakfire::coreupdate_available is replaced with a call to the new Pakfire::coredbinfo.
- Patch 5: Removes core-list.db parsing and upgrade check from Pakfire::upgradecore and move it to the 'pakfire upgrade' routine adding a bit more verbosity along the way.
- Patch 6: Add a new filter 'upgrade' to the 'pakfire list' command. This filter was already available in Pakfire::dblist previously specificly to accomodate pakfire.cgi. Now this filter is also available for the CLI user, displaying a list of only the packages that need updates. Adding core update info as first list entry if an upgrade is available. Also fixed a small bug: previously 'pakfire list --no-colors installed' was not understood. Now it works like the install|remove commands.
- Patch 7: Remove UI elements from the Pakfire::status function now returning a hash with status information. Moving UI part to the 'pakfire status' routine. Replaced pakfire.cgi code duplicating the retrieval of the status info by a call to this Pakfire::status function.
- Patch 8: Adds a Pakfire::getmetadata function to get the metadata of a specific pak in a hash. Both 'installed' or 'latest' metadata can be requested. This function is for use everywhere pak metadata is required without having to know anything about inner working of pakfire db/meta-files. This functions is put in use for a new 'pakfire info <pak(s)>' routine for the CLI user to get all available metadata for a pak. And finaly the main purpose of this patchset: in services.cgi duplicate and or ugly code is replaced with Pakfire::dblist and Pakfire::getmetadata calls to determine which services are installed.
- Patch 9: Changes the workflow of the 'pakfire upgrade' routine. Previously when 'pakfire upgrade' was launched, a core update was immediatly installed. Then available pak updates where listed and user confirmation was asked (when not using -y). Firstly I found it quite rude of pakfire to immediatly perform the core upgrade when it should be 'interactive'. Secondly by then asking user confirmation for the pak updates, it was possible for the user to answer no and end up with a system where the installed addons are compiled against a previous core and probably no longer work. So that is not really a 'free choice' then :-) Now all upgrade info is gathered first and an upgrade summary is presented to the user (more in the style of the output when a pak is installed or removed) and confirmation is requested. Only after the user confirming the upgrade the core and the paks are upgraded in one go (except ofcourse when -y is used, then no confirmation is asked).
Example output of 'pakfire upgrade' now: --- CORE INFO: Checking for Core updates... PAKFIRE INFO: Checking for package updates... PAKFIRE RESV: zabbix_agentd: Resolving dependencies... PAKFIRE RESV: zabbix_agentd: Need to install dependency: fping PAKFIRE RESV: fping: Resolving dependencies...
PAKFIRE INFO: Upgrade summary:
CORE INFO: Core-Update 2.27.2-x86_64 to install: CORE UPGR: Release: 163 -> 165
PAKFIRE INFO: New dependencies to install: PAKFIRE INFO: fping - 30.00 KB
PAKFIRE INFO: Total size: ~ 30.00 KB
PAKFIRE INFO: Packages to upgrade: PAKFIRE UPGR: zabbix_agentd 4.2.6-4 -> 5.0.21-5
PAKFIRE INFO: Is this okay? [y/N] ---
Which looks much cleaner to me than before, and the user has the actual choice to cancel the upgrade before anything happened.
I know it is a big patchset and quite intrusive to the inner workings of pakfire, but I tried to test everything as thoroughly as possible and it should not break pakfire :-). It does make it a bit less errorprone, more robust and future-proof, easier to extend and to use both by the user and in other scripts.
Regards Robin