purging conduwuit after installing continuwuity using the debian specific guide will wipe the database #2148

New issue

Open

opened 2026-08-18 20:36:04 +00:00 by slonk · 4 comments

slonk commented

2026-08-18 20:36:04 +00:00

The continuwuity package conflicts with the old conduwuit package and will remove it automatically when installed.

The purge script currently wipes the database when ran, and installing continuwuity will remove conduwuit, so…

The preferred way to do package transitions in the Debian world is to make the old package virtual instead of replacing it.

https://wiki.debian.org/PackageTransition

#awesome

PS. i dont even agree with the purge script wiping the database instead of just configuration. seems like a massive footgun which i have now shot myself with

> The continuwuity package conflicts with the old conduwuit package and will remove it automatically when installed. The purge script currently wipes the database when ran, and installing continuwuity will remove conduwuit, so… The preferred way to do package transitions in the Debian world is to make the old package *virtual* instead of replacing it. https://wiki.debian.org/PackageTransition #awesome PS. i dont even agree with the purge script wiping the *database* instead of just configuration. seems like a massive footgun which i have now shot myself with ![image](/attachments/a088ead8-d593-4c7b-8a1d-c8e0076c64bf)

image.png

139 KiB

nex added the

Bug

Meta/Packaging

labels

2026-08-18 20:37:09 +00:00

ginger commented

2026-08-18 20:38:13 +00:00

Owner

...oops

❤️ 1

ginger self-assigned this

2026-08-18 20:38:16 +00:00

slonk commented

2026-08-18 21:11:58 +00:00

Author

actually, this part in the service definition saved the database from being deleted:

[Service]
DynamicUser=yes

it caused the actual database to reside in /var/lib/private/conduwuit, and made /var/lib/conduwuit just a mount point in conduwuit's mount namespace. so the purge script doesnt even delete the database..?

here's an excerpt from systemd.exec(5):

If DynamicUser= is used, the logic for CacheDirectory=, LogsDirectory= and StateDirectory= is slightly altered: the directories are created below /var/cache/private, /var/log/private and /var/lib/private, respectively, which are host directories made inaccessible to unprivileged users, which ensures that access to these directories cannot be gained through dynamic user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from perspective of the host and from inside the unit, the relevant directories hence always appear directly below /var/cache, /var/log and /var/lib.

the /var/lib/conduwuit directory will get recreated by systemd on next restart. yall should still move to a virtual package, though

actually, this part in the service definition saved the database from being deleted: ```ini [Service] DynamicUser=yes ``` it caused the *actual* database to reside in /var/lib/private/conduwuit, and made /var/lib/conduwuit just a mount point in conduwuit's mount namespace. so the purge script doesnt even delete the database..? here's an excerpt from [`systemd.exec(5)`](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#RuntimeDirectory=): > If DynamicUser= is used, the logic for CacheDirectory=, LogsDirectory= and StateDirectory= is slightly altered: the directories are created below /var/cache/private, /var/log/private and /var/lib/private, respectively, which are host directories made inaccessible to unprivileged users, which ensures that access to these directories cannot be gained through dynamic user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from perspective of the host and from inside the unit, the relevant directories hence always appear directly below /var/cache, /var/log and /var/lib. the /var/lib/conduwuit directory will get recreated by systemd on next restart. yall should still move to a virtual package, though

❤️ 1

julian45 commented

2026-08-18 22:53:34 +00:00

Member

The preferred way to do package transitions in the Debian world is to make the old package virtual instead of replacing it.

@slonk Would adding Provides: conduwuit to our package fulfill your proposed solution? Otherwise, I’m not sure if this is within our control as a project. Assuming the old conduwuit package was provided by the project of that name, that project has been archived for over a year.

> The preferred way to do package transitions in the Debian world is to make the old package *virtual* instead of replacing it. @slonk Would adding `Provides: conduwuit` to our package fulfill your proposed solution? Otherwise, I’m not sure if this is within our control as a project. Assuming the old `conduwuit` package was provided by the project of that name, that project has been archived for over a year.

slonk commented

2026-08-18 23:25:31 +00:00

Author

@julian45 wrote in #2148 (comment):

The preferred way to do package transitions in the Debian world is to make the old package virtual instead of replacing it.

@slonk Would adding Provides: conduwuit to our package fulfill your proposed solution? Otherwise, I’m not sure if this is within our control as a project. Assuming the old conduwuit package was provided by the project of that name, that project has been archived for over a year.

im not a debian packaging expert but i assume no, it wouldnt. however, you do require users to add a repository in which you could easily provide a virtual conduwuit package with version last release + 1 (or just 999), which is how other repos do it afaik

furthermore, e-mail replies are broken (or just extremely delayed?)

@julian45 wrote in https://forgejo.ellis.link/continuwuation/continuwuity/issues/2148#issuecomment-34412: > > The preferred way to do package transitions in the Debian world is to make the old package _virtual_ instead of replacing it. > > @slonk Would adding `Provides: conduwuit` to our package fulfill your proposed solution? Otherwise, I’m not sure if this is within our control as a project. Assuming the old `conduwuit` package was provided by the project of that name, that project has been archived for over a year. im not a debian packaging expert but i assume no, it wouldnt. *however*, you do require users to add a repository in which you could easily provide a virtual `conduwuit` package with version _last release_ + 1 (or just 999), which is how other repos do it afaik furthermore, e-mail replies are broken (or just extremely delayed?)