[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#966537: ITP: tomboy-ng -- Cross Platform Notes



Ben, I am not sure if I am allowed to answer here, don't want Bart to
slap me down again.

If I have it wrong again, very sorry, will withdraw....


On 3/8/20 4:34 am, Ben Hutchings wrote:
> Gtk+ 2 is deprecated, and we should not add new applications using it.
> So it sounds like the best option for now would be to build it with Qt
> support only.  Why is that limited to 64-bit architectures?

Ben, most distros are still shipping GTK2 and most don't ship Qt5. So,
at present, it sort of makes sense to use GTK2 from the point of view of
the average user. The point is that with Lazarus, its trivial to switch
from GTK2 to QT5 at compile time so, in a way, tomboy-ng is not really a
GTK2 app, it can be what ever is decided at compile time.

The Qt5 version is dependent of a shim library, libqt5pas that is
available in most newer distributions but 64bit only.  Thats apparently
because the upstream libraries that are needed to link to it are not
available.

The Lazarus people maintain and develop libqt5pas but I make binary deb
and rpms available at https://github.com/davidbannon/libqt5pas for
people using older distros such as Ubuntu18.04. Its no useful at all for
eg U16.04. I expect the same applies to Stretch, have not tested Qt5 on
Buster.


> Depending on what your script does, the 'kit' might not include what we
> would consider the full source code.  The script itself would also need
> to be made public, usually as part of the source package.
>
> It is generally preferable for Debian source packages to start from a
> tarball that exactly matches an upstream release.

Absolutely !  What I have been doing while I play with this model is to
download a zip file from github, I run a script that unzips and inserts
in the dependency source, kcontrols. It then makes the
tomboy-ng.orig.tar.gz file that exactly matched the new created working
dir. debuild will run and make the files that go towards the SRC DEB. 
Together they make a quite conventional SRC DEB kit.

As a side note, that first script also sets up some things that are
useful for people like me who have FPC or Lazarus installed in user
space.  Many Lazarus developers keep Lazarus in userspace rather than
install from a deb, there are good reasons. But this is irreverent to
building a SRC DEB where we assume both FPC and Lazarus are root installed.

That script, and one called by the Makefile are bundled in the zip file
downloaded from Github.  

>
> In any case this will have to go into unstable first, and then (if all
> goes well) it can go into bullseye and maybe buster-backports.  It
> won't be added to buster as we don't add new applications to stable
> releases.

That all sounds great. I am starting to understand the Debian process,
but just starting !

Davo


Reply to: