Suppress display of dependencies on pakfire.cgi main page

Suppress display of dependencies on pakfire.cgi main page

[stephen]

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

Re: Suppress display of dependencies on pakfire.cgi main page

[Michael Tremer]

Hello Stephen,

Apologies for the late response. May mailbox is overflowing as usual.

> On 12 May 2025, at 20:15, stephen@firemypi.org wrote:
> 
> 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.

I like the idea, and I have some plans for IPFire 3 regarding this, but I am not sure this is *that* easy.

Most packages that we would classify as a dependency have very little purpose on their own, but that does not mean that there isn’t any. Ghostscript for example can convert files even though that data is not going to be printed by CUPS in the end. Should people do this on the firewall? That is a totally different debate.

A huge downside would be that there is going to be a discrepancy between what you can do on the CLI and what you can do on the web UI. Packages just “disappear”. I would ask the question whether that is not more confusing than having a number of packages that serve rather little purpose.

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

True. The name itself would not be sufficient as “libvirt” for example is a leaf and not a dependency in the tree, despite the name.

> 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 think this would generally be possible. It would be subject to testing, because under no circumstances we can break those existing installations that are on older versions of Pakfire.

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

Correct. The package index is being generated on the master mirror server.

What I would personally find more interesting is to add the description here, so that we can show people more about what the package does.

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

I understand your approach, but it does indeed have a couple of problems. Even though if we could iron them out for now with the proposed changes below, experience tells me that sooner or later you will have another case where this plan is no longer working out.

If we want to hide some packages from the web UI, I would rather suggest that we add a flag that tells Pakfire whether to show or hide the package. We don’t have that many packages anyways, so this should not be a major headache.

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

This is needed when RADIUS is being used to authenticate against an Active Directory system. I run this in a few places.

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

But without QEMU, libvirt cannot run anything. It would just try to launch a virtual machine, but the actual code to run it would not be available.

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

Pakfire in IPFire 2 does not have any weak dependencies. We usually go by the rule that there is little point in using the frontend without the backend (same case with libvirt). What are all those buttons worth when in the end there is nothing happening in the background?

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

rsync is a hard dependency for rsnapshot, but obviously not the other way around.

> 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?

Same as above.

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

I don’t think we should go this way. I understand the goal and I agree with it, but separately selecting the packages that would be shown sounds a lot easier for me without breaking packages and cutting off any functionality that people out there are actually using.

-Michael

> Regards,
> Stephen
> 
> 
> 
> 
> 
>