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
--
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.