This repository has been archived by the owner on Nov 25, 2022. It is now read-only.
Creating a debian package #299
Labels
Comments
|
great ... quickly tried as to "SONAME" i think "-core" is fine. and following the tag versions as well, i think. Right now we'd be at some post 0.20.0 dev version i guess. could you maybe check your current deb package build into a |
|
holger krekel <notifications@github.com> writes:
great ... quickly tried ``dpkg -i libdeltachat-core_0.20.0-1_amd64.deb`` but it fails ...
```
dpkg: dependency problems prevent configuration of libdeltachat-core:
libdeltachat-core depends on libssl1.1 (>= 1.1.0); however:
Package libssl1.1 is not installed.
```
Yeah, this exposes two problems:
1. the problem with using dpkg to install packages... dpkg does not do
dependency resolution and installation automatically, like apt does.
You may be able to do ``apt-get -f install` after the above fails for it
to pull in libssl1.1, but that leads to problem #2
2. packages are built for specific debian versions, and dependencies are
generated for the versions that it was built for. I built the
libdeltachat package on debian sid, which picked the available
dependency of libssl1.1 because that one was available.
Fortunately, libssl1.1 is available in stable, testing and unstable at
the moment, but it is not available in jessie (old stable) and it may
not be available in all versions of Ubuntu (especially the LTS
versions).
This is why a debian *source* package is usually produced, which then is
used to build a *binary* package that matches the dependencies for the
release.... which brings up the final point:
I built this under amd64 architecture, it would need to be rebuilt for
other architectures to be useful (such as armel, armhf, or
whatever... android architectures are not amd64!)
This is why debian has a build farm which builds things for different
architectures and for the different releases.
could you maybe check your current deb package build into a ``deb/``
subdir of this repository?
I can do that, there are some arguments for keeping the debian build
pieces separated from the upstream source, but maybe we can double-cross
that bridge when we come to it.
|
|
On Sun, Sep 23, 2018 at 10:58 -0700, micah wrote:
> could you maybe check your current deb package build into a ``deb/``
> subdir of this repository?
I can do that, there are some arguments for keeping the debian build
pieces separated from the upstream source, but maybe we can double-cross
that bridge when we come to it.
we can also do a "deltachat/debian" dedicated repository. If you don't
have the rights (i think you have) to create one, let me know.
|
|
i think this is done :) https://tracker.debian.org/pkg/deltachat-core thanks everyone who pushed this forward :) |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Holger mentioned that it would be good to make a debian package of the libdeltachat library. I'm a Debian Developer, and can do this, but I do not have very much knowledge of shared libraries and the policies in Debian around them. The idea is to put a .deb up somewhere that can be linked to from the web pages to help people install py (and possibly js) bindings without running in to dependency issues or weird /usr/local/* stuff.
This should ideally be plugged into a CI to build this on every commit, but perhaps this would be too much of a bleeding edge package to provide people, so in the meantime, to provide something to get started, I built a package off of the latest tag (0.20.0).
I have a few questions:
Typically a shared library has an ABI version number as part of its SONAME. I noticed that there was none for libdeltachat, do you plan on setting one, or can I use zero to begin with.
Debian library packages are typically named lib[libraryname][SONAME-version-number]" so we would create libdeltachat[SONAME] and then the development files/header files would be created in a different package called libdeltachat[SONAME]-dev. Holger mentioned that only deltachat.h needs to be installed for the development libraries, as the other .h files are 'private'.
I noticed that 'git' is needed to build, but I didn't figure out why exactly, I think it had to do with the embedded netpgp. Do you happen to know?
Regarding the bundled libraries... How can I tell mason to build without them, and which of them are specifically modified in the bundled version, different from the upstream version?
I've attached to this issue the built .deb files from the 0.20.0 tag. These are by no means complete, but they provide a the shared library and the .h file. More work should be done to make them better.
libdeltachat-deb.tar.gz
The text was updated successfully, but these errors were encountered: