xapian installed
Closed, ResolvedPublic

Description

for unknown reasons apt-xapian seems installed and running. determine why it is pulled in and if we can get rid of it.

sitter created this task.Mar 30 2018, 11:04 AM
sitter triaged this task as Low priority.Apr 5 2018, 2:09 PM

we still seed qapt-deb-installer. we can actually drop that though, UX-wise I think this is fully replaced by discover already (i.e. you'd have to explicitly open with qapt-deb-installer to use it)

qapt-deb-installer -> libqapt -> apt-xapian

oof

new chain

00:06:04.447         Installing software-properties-kde as Recommends of plasma-discover
00:06:04.451           Installing qapt-batch as Depends of software-properties-kde
00:06:04.452             Installing libqapt3-runtime as Depends of qapt-batch
00:06:04.454               Installing libqapt3 as Depends of libqapt3-runtime
00:06:04.455                 Installing libxapian30 as Depends of libqapt3
00:06:04.456                 Installing apt-xapian-index as Recommends of libqapt3

needs code inspection if that still applies. I kinda recall that software-properties uses qapt-batch to update though, so this is probably fairly necessary. whether discover should depend on software-properties is another question to which I guess the answer is no.

software-properties

softwareproperties/kde/SoftwarePropertiesKDE.py:                cmd = ["/usr/bin/qapt-batch", "--update"]

discover

libdiscover/backends/PackageKitBackend/PackageKitSourcesBackend.cpp:    auto service = PackageKitBackend::locateService(QStringLiteral("software-properties-kde.desktop"));

:(

so, iff s-p is installed it is listed as a startable service in the settings' burger menu to give access to more advanced options. meaning we could opt to not ship it by default as it is not necessary. OTOH maybe the way to go is to do something with s-p where we check for qapt-batch OR pkcon to do the cache update. then again the two aren't equal as the point behind qapt-batch is that it gives a gui whereas pkcon doesn't and python-apt doesn't either unlesss a custom one is written which was decidedly avoided here.

So, after a look I'd say discover needs s-p to actually edit sources. packagekit doesn't allow editing, only enable/disable and deleting sources, so s-p is necessary to actually manage the sources.lists as such I think we are probably better off keeping it.

now what we could do is add a simple flag to software-properties to use pkcon instead of qapt and then rip out qapt from the default ISO.

so discover calls s-p --pkcon or somesuch and it would then run pkcon refresh on exit. meaning we keep everything working but can avoid qapt on the ISO. this would be rather fidly though, I'll have to think about it a bit

I don't have this installed. Needs checked if it got sorted or if we stopped installing s-p-k even though we still need it

sitter closed this task as Resolved.Feb 21 2019, 1:35 PM
sitter claimed this task.

This may have rejuggled a bit by changing qapt around.

the actual relationship of discover was lost in
https://packaging.neon.kde.org/kde/plasma-discover.git/commit/?h=Neon/release&id=be56871b923f45eac2ed00ad1dca33afb8a513bf
BUT at least today discover still (can) use s-p-k, so technically we should depend on it but don't.

seeing as the original issue was about apt-xapian I am going to close this though :P