Rename jw.pkg.cmds.distro.backend.BackendCmd to Backend, because it's not necessarily a command, i.e. doesn't necessarily have a run() method. It's more of a distribution abstraction of the steps needed for for a specific command, the run() method itself is implemented in jw.pkg.cmds.distro.CmdXxx.
This commit is the beginning of a bigger move to change the distribution backend class hierarchy. At the end of this change set, the backend command should not derive the backend classes from a base specific to the respective distribution, but from an abstract base class specific to the command run. The distribution specifics are then going to be encapsulated in another class called "Util", an instance of which is going to be provided to the backend as .util member.
Move the body of BackendCmd.sudo() into a function. The rationale behind that is that its functionality is independent of the calling object for the most part, so having it in a function instead of a method is the more modular pattern.
This commit allows pgit.sh to target not only multiple projects below a projects-directory, but also one single project. If invoked from the toplevel directory of a project, it uses that as the only project it should deal with. This is meant to facilitate running the same VCS abstraction logic for one project as for many projects. The project or projects to deal with should probably be specified on the command line, but changing the auto-detection mechanism buys us what we want for now with low hassle.
Some variable names are too short for global scope ($p, $pdir, $pdirs), among others. For those mentioned: Make them longer and more descriptive.
Also add a variable project_name, which denotes what a project is in a remote repository, and which is currently but not necessarily always the same as the project directory.
Add more fields to the OS cascade returned by App.os_cascade, based on the ID field in /etc/os-release. This includes some new ones, prefixed by pkg-, revealing which package format is used.
apt-get install suggests it wants to be called with -f to clean up some mess left behind from a previous install. Adding -f in the hope add it to the install options by default. OTOH, it wants to be called that without arguments, not sure if always passing it along is a good idea.
The man page says:
-f, --fix-broken
Fix; attempt to correct a system with broken dependencies in place. This option, when used with install/remove, can omit any packages to permit APT to deduce a likely solution. If packages are specified, these have to completely correct the problem. The option is sometimes necessary when running APT for the first time; APT itself does not allow broken package dependencies to exist on a system. It is possible that a system's dependency structure can be so corrupt as to require manual intervention (which usually means using dpkg --remove to eliminate some of the offending packages). Use of this option together with -m may produce an error in some situations. Configuration Item: APT::Get::Fix-Broken.
Also turn the short options -yq into long options --yes --quiet for more obvious debugging if something goes awry.
Not logging any attribute for links, as it's now, breaks Debian's parser. So, log %attr(0777, $owner, $mode). This fixes the parser on the Debian side and hopefully leaves the RPM side intact.
CmdGetAuthInfo calls run_cmd() with a list instead of a *-expanded list of arguments. Fix this to match the current run_cmd() prototype.
And think again if the current prototype conforms to the priciple of least surprise: Most exec- / run- / whatever- functions do expect ether a string to be run by the shell, or an argv list.
Prepending --login to the argument list of BackendCmd.sudo() fails if run as root, because BackendCmd.sudo() detects that and leaves the /usr/bin/sudo out from the exec call. Fix that by adding an opts: list[str] parameter to sudo, defaulting to an empty list, with options that should be passed to /usr/bin/sudo.
Define run(), which calls _run() in the abstract base class Cmd, not in lib.Cmd. Otherwise lib.Cmd is not abstract, which will predictably confuse including code outside of jw-pkg.
If VERSION_FILE is not found, trying to include makefile snippets triggers the attempt to regenerate it. This happened for installed Makefiles of jw-docker-images: It defines TOPDIR to /opt/jw-docker-images, projects.mk looks there, but the version file is installed under /usr/share/doc/packages/jw-docker-images/VERSION.
Allow VERSION_FILE to be overridden including code to keep that from happening.
make complains for plugins that soandso.dll has not been remade. The problem is that it tries to remake all targets of a multi-target. Split that up into two rules.
Calling make git-pull-xxx from a projects directory stops iterating projects if one has a dirty workspace. Calling --autostash fixes that.
With this in place, a failed rebase leaves the local changes behind stashed. So, after manually fixing the rebase, the stash needs to be manually reapplied. The commands that led up to the failure are logged right before, so I have hope that this is learnable, and not too much of a footgun.
.cache-projects.mk is not installed / packaged, which makes builds against an installed jw-pkg considerably slower. Change that, at the risk of making the installed jw-pkg-devel less versatile. This commit installs a cache file cache-projects.mk, renamed from .cache-projects.mk, because there's no justification for hiding an installed makefile. At least I can't think of one.
Before merging the remote branch, do a rebase. This may fail and prompt conflict resolution, but that seems the canonical outcome for the common use case "interactive make git pull-xxx" with master out-of-sync.
