I build signal-desktop from source. The vanilla build process following the official directions produces a .deb package, which I then convert to a .txz using deb2tgz. The packages install just fine but when upgrade time comes, using upgradepkg I get the following error:

upgradepkg ./signal-desktop_6.12.0-beta.1_amd64.txz

Error: there is no installed package named signal-desktop_6.12.0-beta.1_amd64.
(looking for /var/lib/pkgtools/packages/signal-desktop_6.12.0-beta.1_amd64)

and of course.. signal desktop IS installed, as a quick ls of /var/log/packages/ reveals:

ls /var/log/packages/ | grep signal

signal-desktop_6.11.0-beta.1_amd64

Until now I have just forced the upgrade using '%' with upgradepkg, but I would like to modify the package so that it upgrades simply & correctly, like almost all other slackware packages. Honestly, signal is the only package that makes me do this. Is there something I can add to the package (doinstall.sh?) that would make it update correctly?

I just need to be pointed in a direction here. Signal has a complicated build process with a lot of dependencies and frameworks involved. It's a right proper Charlie Foxtrot, but in the end it still produces useable packages. At the same time, it's not the usual ./config && make && make_install build process that I am dealing with here, so I don't expect anyone to martyr themselves figuring out the exact process to correct this issue.

All I need is to be pointed in a direction here. I suspect something is missing from a .deb that is present in a correctly made slackware package, and adding that missing thing would probably correct this issue.

Or, can I add an entry for signal-desktop to the package database directly?

I just need some suggestions here, I can do the heavy lifting myself. As I said, the build process for signal is a fussy, finicky CF, but it's a good product so I put up with the BS that comes with design decisions made by the upstream developers.

.

upgradepkg --install-new *.txz

upgradepkg --install-new *.txz

Quick and elegant. I learn something new every day.

I must admit that I only read your first 3 lines

Well, it works and it's less hassle than troubleshooting Signal's convoluted build process (which the developers could elect to change at any time, taking me right back to square 1 again..)

or troubleshooting the package that process produces, and at the end of the day, everything still works.

Like Voltaire, I won't allow the "perfect" to become the enemy of the "good enough" here..

1 members found this post helpful.

Just in case:
If you make some test and recompile a package, leaving the same version of $BUILD

you can reinstall with :
upgradepkg --install-new --reinstall *.txz

1 members found this post helpful.

It's a malformed name: there should be at least three dashes. It's packagename-version-architecture-buildnumber.txz, fields read from right to left separated with dashes. If you rename it to signal-desktop-6.11.0_beta.1-x86_64-1.txz then you have:

packagename signal-desktop
version 6.11.0_beta.1
architecture x86_64
buildnumber 1

The architecture part must be set correctly. It should be x86_64 for the 64-bit slackware or noarch if the package is independent of the architecture.

6 members found this post helpful.

Edit: Petri Kaukasoina beat me to it.

My

You are getting the message because "signal-desktop_6.12.0-beta.1_amd64.txz" is not a properly formatted Slackware package.

What is a properly formatted package?

name-version-arch-build.typepkg (at least five segments)

"name" can be up to four segments, e.g, name1-name2-name3-name4-version-arch-build.typepkg (eight segments)

Why did upgradepkg produce the error?

To search /var/lib/pkgtools/packages it needs get the the "name" out of the "package name". Which looks like it should be "signal-desktop". Unfortunately because "signal-desktop_6.12.0-beta.1_amd64.txz" is not properly formatted, upgradepkg fails when looking in /var/lib/pkgtools/packkages.

To get the "name" out of "signal-desktop_6.12.0-beta.1_amd64.txz":

First, upgradepkg drops the ".txz" from "signal-desktop_6.12.0-beta.1_amd64.txz"
Second, upgradepkg test that there are at least four segments in "signal-desktop_6.12.0-beta.1_amd64".
That test fails, there are three segments. So "signal-desktop_6.12.0-beta.1_amd64" is used for "name"
This causes the failure when looking in /var/lib/pkgtools/packages for "signal-desktop_6.12.0-beta.1_amd64", "signal-desktop_6.12.0-beta.1_amd64" does not exist in /var/lib/pkgtools/packages.
Note with an "in spec" "name" with at least four segments test, last three segments (version-arch-build) are dropped leaving the "name", in this case with a properly formatted package it would be "signal-desktop".

'upgradepkg *.txz' will fail on "signal-desktop_6.12.0-beta.1_amd64.txz"

'upgradepkg --install-new *.txz' works because the "name" "signal-desktop_6.12.0-beta.1_amd64" cannot be found /var/lib/pkgtools/packages so to upgradepkg "signal-desktop_6.12.0-beta.1_amd64" is new.

May as well use:
installpkg signal-desktop_6.12.0-beta.1_amd64.txz, in this case it is the same thing.

do an 'ls -1 /var/lib/pkgtools/packages/signal*' or "ls /var/log/packages/ | grep signal" as see what you get.

What the solution?

first:
'removepkg" /var/lib/pkgtools/packages/signal-desktop_6.11.0-beta.1_amd64'
'removepkg /var/lib/pkgtools/packages/signal-desktop_6.12.0-beta.1_amd64'

second:
'mv signal-desktop_6.12.0-beta.1_amd64.txz signal-desktop-6.12.0-beta.1-amd64.txz'
-OR-
'mv signal-desktop_6.12.0-beta.1_amd64.txz signal-desktop-6.12.0_beta-1.amd64.txz'
-OR even-
'mv signal-desktop_6.12.0-beta.1_amd64.txz signal-desktop-6.12.0_beta-amd64-1.txz'

As long as it meets the "in spec" package name. Do this from now on.

Then use installpkg or upgradepkg on the newly name package.

The real solution in my opinion is to use SBo, there is a signal-desktop listed. I bit out of date, just change the VERSION variable.

My preferred solition with be to make my own SlackBuild, but that's just me.

4 members found this post helpful.

I want to add. I created a package and installed deb2tgz to play with it. Doesn't do much aside from turning a deb to a txz. There doesn't seem to be a way to add a slack-desc or doinst.sh to the package either and it does nothing to output a proper package for Slackware, not to mention any fixes that might be needed.

That all said, I guess it is a quick and dirty way to make a Slackware package from a Debian package. So it is a useful tool. It's easy to rename a file.

1 members found this post helpful.

It's a malformed name: there should be at least three dashes.

Good to know. I read something about naming conventions for packages and skimmed right past it, assuming "Nah, that couldn't be the source of the problem.."

But it makes perfect sense, in hindsight.

I guess it is a quick and dirty way to make a Slackware package from a Debian package. So it is a useful tool.

Basically, yes. It's not my first choice, but sometimes it's the simplest solution.

The dependencies and build process for Signal are a CF. I like the software but it's one of the
fussiest build processes out there.

Between Signal and PaleMoon browser, not sure which one gets the gold medal for being and CF and
which gets the silver medal.

I may switch over to the slackbuild option, now that I am familiar with the ins and outs of compiling Signal "their way"..