[0/9] pakfire: remove dup. code + seperate ui/logic

  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
  

On 03/09/2022 5:56 PM, Robin Roevens wrote:

[snip]

> 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).

[snip]

BRAVO!!! This behavior has always bothered me, too. Combined with the 
fact that "pakfire update" didn't tell you whether an update was 
available, it was quite frustrating, requiring a "pakfire status" to 
know if an update was available, first.

I also frequently ended up coming back to a console/terminal and finding 
a partially completed upgrade process waiting for me to press "Y".

Tom
  

On 3/9/22 17:46, Tom Rymes wrote:
> On 03/09/2022 5:56 PM, Robin Roevens wrote:
>
> [snip]
>
>> 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).
>
> [snip]
>
> BRAVO!!! This behavior has always bothered me, too. Combined with the
> fact that "pakfire update" didn't tell you whether an update was
> available, it was quite frustrating, requiring a "pakfire status" to
> know if an update was available, first.
>
> I also frequently ended up coming back to a console/terminal and
> finding a partially completed upgrade process waiting for me to press
> "Y".
>
> Tom

Double Plus Good.

Paul