From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4gX0pk1Cjbz30VM for ; Fri, 05 Jun 2026 12:18:54 +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 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4gX0pg1HQwz2xJ5 for ; Fri, 05 Jun 2026 12:18:51 +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 4gX0pb5WnlzV2; Fri, 05 Jun 2026 12:18:47 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1780661927; 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=tESLoE541M9+BAEOrmi5zfA1IKAmXMTrahrBi6TAinI=; b=n5cLL2iqbCA9q6F1KM8l844kQJA7hVF+oGStbhYbasQ59imNxDqwqPyecNTle1vXgBXPLe JVHbWd5kLhGcC+CQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1780661927; 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=tESLoE541M9+BAEOrmi5zfA1IKAmXMTrahrBi6TAinI=; b=lm9+UBAwBi6X1XDjZsyvpRJU8HnID8W+v5U8fuag94hc8tjdD+xQM7m5S3HSXjm8eIL/X8 2dsnY9TC5G/RTXs6TfZXNrolFB400Ozkf5wn93WfLr6AKlSZiIYmWZ6hfH5Cgvt0A4z+tx jkqP49r6p49/PPoqK8Z89QY8EWRrI8oxzRBxx7Ahozf5PZvZKqj+Ev1UWdH/4ACOBxf5SW VsNsLXD4i4TFeyrM5c7+lwRlBjBskGG/IY1cq3Km0J9A/IYmRK1ocDeQslBOQ520U3L7/D 9DH0lLAoC8C+2aVGL77K9sCEyGEsvc/fS0+zRFfWeE2pvEFLBvi3tHi/carOFA== 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: Splitting bundled database file out from auto-update flow From: Michael Tremer In-Reply-To: Date: Fri, 5 Jun 2026 13:18:46 +0100 Cc: IPFire Location Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <6B1ADCD0-133A-4078-B1D7-3E04B437EC19@ipfire.org> References: <04AAA98E-3C11-4857-8452-B11753AFC6A3@ipfire.org> To: Valters Jansons Hello, > On 5 Jun 2026, at 12:35, Valters Jansons = wrote: >=20 > I can understand the concern for redundant disk space usage. >=20 > It's actually Debian packaging that I am concerned about. >=20 > For your ClamAV reference, I cannot find where the current release > ships its database file inside the package manager. There are > references to a clamav-data package, which would do this, but I cannot > find the package itself right away -- > = https://salsa.debian.org/clamav-team/clamav/-/blob/unstable/debian/control= #L120 My information might be outdated. We packaged libloc for bookworm and = the approach for clamav might have changed since then. I don=E2=80=99t maintain that package, so I would be happy to learn if = there are new rules. > Instead, they seem to expect clamav-freshclam binary to be installed > which would dynamically download the file -- > https://packages.debian.org/sid/all/clamav-freshclam/filelist Yes, this would pretty much happen very quickly after the package has = been installed, but we decided that we want at least *some* database to = be available immediately. It will be outdated, but it is better than = nothing. > In any case, I did a double-take on this, and it seems that Apt will > clobber the database file. It would only cause confusion for > configuration file directories, and /var/lib should be outside of that > scope. I would still suggest a /usr/share/location/database.db for > fallback, which could be packaged. But the doubled disk space usage > concern still stands, and it adds increased complexity on top of > current simple database file selection. I don=E2=80=99t think it would be too complex, but more complex than = what we have now indeed. > So I digress, it sounds reasonable to leave it as-is. >=20 > Thank you for the quick response in any case, and wish you a nice = weekend! No problem. I appreciate your thoughts and patches very much. So please = keep them coming. Best, -Michael > Best regards, > Valters Jansons >=20 > On Fri, Jun 5, 2026 at 8:11=E2=80=AFPM Michael Tremer = wrote: >>=20 >> Hello Valters, >>=20 >> No, this has not been considered before, but it is always brought up = for discussion whenever someone packages this for a new distribution = because they have all different rules. >>=20 >> We followed the process of Debian and how they package clamav for = example which also comes with a packaged database that will be updated = by a third tool and the package manager will just have to deal with it. >>=20 >> I am not against having multiple paths where the database is being = opened from, although I don=E2=80=99t think it is a good investment of = disk space. The database is currently slightly over 40 MiB extracted, so = I wouldn=E2=80=99t want to spend the space twice. Especially since the = old database is not of any use after a newer version has been = downloaded. >>=20 >> I am happy to accept patches if this suites your use-case for as long = as the current one for Debian, Fedora and IPFire is not being modified. >>=20 >> Which distribution are you packaging this for that has these = requirements, or is this a private project? >>=20 >> Best, >> -Michael >>=20 >>> On 5 Jun 2026, at 12:05, Valters Jansons = wrote: >>>=20 >>> Hello, >>>=20 >>> Currently, I have a bit of a concern for package managers and the >>> database file updates. >>>=20 >>> The location tool wants to update /var/lib/location/database.db --- >>> however, there is also logic to bundle this file in package = managers. >>> So, when there is a new package version, the package manager = believes >>> it should be in charge of the file. When it looks at the update, it >>> sees that the "user" has made changes to the file. This results in a >>> conflict, and potentially a confusing message stating that the user >>> has made modifications to the file, while it has been automatic >>> updates. >>>=20 >>> It would be nice to split it into two distinct locations - one file >>> being modified only by the package manager (to be used as a = fallback), >>> and the other file being the live dynamic auto-updated choice. Has >>> there been any consideration for supporting such a set-up? >>>=20 >>> Best regards, >>> Valters Jansons >>>=20 >>=20