From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4b5YJb6b3Mz32vw for ; Mon, 26 May 2025 11:22:23 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) client-signature RSA-PSS (4096 bits)) (Client CN "mail01.haj.ipfire.org", Issuer "R10" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4b5YJX32vcz2xng for ; Mon, 26 May 2025 11:22:20 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4b5YJV4Dpfz20D; Mon, 26 May 2025 11:22:18 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1748258539; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g8GUs8toFWrOFcFsAuBCSlIWez5lV4330YTlcXbU9d4=; b=6AC+ZHxWZED3n5vwBsEjSWEm4YQWpjFQmTLlDkhu+qRMrP2/z+vVM4+qo6WIkGXqkmG8oi GhkbF/0ZMbmrgDAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1748258539; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g8GUs8toFWrOFcFsAuBCSlIWez5lV4330YTlcXbU9d4=; b=pH4q1osr1SWiGojTCuhCIx9afmjnATB7myKpOElRJtIf6lTBSjfRy5N60eWglH2qi4CKnv 2PZ1AFLgYlrzM6peKk95PEibXLHa+CqejPnjW1MlfjEl12GVwrRZbhRt9Vn51sUQT/RNbX QABzglfhO4ZijPHtgnzrNaOmOauz4Tnid5F13RGV8QmzQrc3D6lF+i1fh+16Do/iO/5qUZ wvsoZuGbY0WBqBbPzP46EQzx/G2/Bot8z8Ffz1hDpUG00hjT45bcayQR7aGpC3ivtFT4mU XXu9MWgQEaT2yACnt5KnX9qKmK5bGGDfPnkeLAHFC1j6ZDHTDuDQdXm5qksaUw== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: Suppress display of dependencies on pakfire.cgi main page From: Michael Tremer In-Reply-To: <598570bc-905b-4937-9d71-75b1fb55a006@firemypi.org> Date: Mon, 26 May 2025 12:22:14 +0100 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: <51B7F8F6-C9AA-4A3D-B01E-06C4917CF7D2@ipfire.org> References: <598570bc-905b-4937-9d71-75b1fb55a006@firemypi.org> To: stephen@firemypi.org Hello Stephen, Apologies for the late response. May mailbox is overflowing as usual. > On 12 May 2025, at 20:15, stephen@firemypi.org wrote: >=20 > Hello, >=20 > One of the changes that I want to make to pakfire.cgi is to remove the = dependencies from the 'install' and 'remove' , 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 =E2=80=9Clibvirt=E2=80=9D= 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: >=20 > package name;package version;addon version;list of dependencies; >=20 > This change shouldn't affect pakfire since pakfire uses @templine =3D = 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' , the dependencies for installed packages are = available in /opt/pakfire/db/installed so this is doable. >=20 >=20 > 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: >=20 > freeradius:DEPS =3D libtalloc samba > libvirt:DEPS =3D ebtables libpciaccess ovmf qemu > mpc:DEPS =3D mpd libmpdclient > mympd:DEPS =3D mpd libmpdclient > rsnapshot:DEPS =3D rsync > vdradmin:DEPS =3D perl-gettext vdr vdr_epgsearch >=20 > 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=E2=80=99t have that many packages anyways, so this = should not be a major headache. > freeradius:DEPS =3D 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 =3D 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 =3D mpd libmpdclient > mympd:DEPS =3D 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 =3D 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 =3D 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: >=20 > 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. >=20 > It probably would be a good idea if the actual package maintainers for = these add-ons weigh in on this. :) I don=E2=80=99t 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 >=20 >=20 >=20 >=20 >=20 >=20