Hello,
One of the changes that I want to make to pakfire.cgi is to remove the
dependencies from the 'install' and 'remove' <select> boxes on the main
page.
Two reasons for this are:
1. Less clutter - don't have to scroll through through a bunch of libs,
perls and python3's to get to the zabbix add-on that you want to install.
2. Dependencies shouldn't be installed by themselves. There is no
reason to since pakfire handles the installation of dependencies.
This would further abstract the dependencies from the installation of a
package, but I think that for the average sysadmin this wouldn't be an
issue.
For the 'install' <select>, I can suppress the libs, perls and python3's
pretty easily which removes 69 rows, but, aside from downloading all of
the metafiles, there isn't enough information on the system to suppress
all of the dependencies.
Would it be possible to add the list of dependencies for a package to
packages_list.db so that we would have:
package name;package version;addon version;list of dependencies;
This change shouldn't affect pakfire since pakfire uses @templine =
split(/\;/,$line); and this would just create a $templine[3] which
pakfire wouldn't use.
I couldn't find where packages_list.db is being created in ipfire-2.x so
I'm guessing it's somewhere in the mirror system.
If that information were available, all dependencies could be removed
from the 'install' <select>.
For the 'remove' <select>, the dependencies for installed packages are
available in /opt/pakfire/db/installed so this is doable.
However, there are some cases of a top level package having another top
level package as a dependency that would affect both 'install' and
'remove'. Here are the ones that I found:
freeradius:DEPS = libtalloc samba
libvirt:DEPS = ebtables libpciaccess ovmf qemu
mpc:DEPS = mpd libmpdclient
mympd:DEPS = mpd libmpdclient
rsnapshot:DEPS = rsync
vdradmin:DEPS = perl-gettext vdr vdr_epgsearch
In these cases, it's easy enough to keep those packages on the lists,
but some of these raised question to me as to whether they are *really*
dependencies. I don't use any of these packages but did some research
and here are my thoughts.
freeradius:DEPS = libtalloc samba
Can samba be removed as a dependency of freeradius? While samba is
commonly used with freeradius as a connector to active directory,
freeradius by itself is a standalone product.
libvirt:DEPS = ebtables libpciaccess ovmf qemu
Can qemu be removed as a dependency of libvirt? libvirt provides an
interface to qemu and other virtualization systems, but doesn't
specifically depend on any of them.
mpc:DEPS = mpd libmpdclient
mympd:DEPS = mpd libmpdclient
Can mpd be removed as a dependency of mpc and mympd? mpc and mympd are
both frontends to mpd. You could install one or the other or maybe
both and although it wouldn't make sense to install them if you didn't
have mpd. I looked on another distro and didn't find mympd, but did
find for mpc that mpd is under "Suggests:" not "Depends:" so my though
would be to remove the mpd dependency for these and leave it up to the
user to install mpd and then pick the frontend rather than picking the
frontend and having that install mpd.
rsnapshot:DEPS = rsync
On the other distro that I looked at rsync does show under "Depends:"
for rsnapshot so this would need to be handled as a one off.
vdradmin:DEPS = perl-gettext vdr vdr_epgsearch
vdradmin is a frontend for vdr. "VDR-Admin is a daemon that
communicates with VDR and shows informations in a Internet browser which
opens the adress of the VDR computer with port 8001." Similarly to mpc
and mympd, can we remove this as a dependency for vdr and let the
sysadmin install it separately if desired?
So to summarize:
Remove samba as a dependency of freeradius.
Remove qemu as a dependency of libvirt but keep libvirt in the list as a
top level package even though the name does start with 'lib'.
Remove mpd as a dependency of mpc and mympd.
Code an exception to always display rsync as a top level package.
Remove vdr as a dependency of vdradmin.
It probably would be a good idea if the actual package maintainers for
these add-ons weigh in on this. :)
Regards,
Stephen
