I know of no OS that uses /opt according to older FSH documenation. There might be, but it's none of the BSDs, macOS or any Linux distribution that I have come across. That same site also has the section for /usr/local and describes its historic purpose and its use today.

Nowadays /opt is for software that fits the description "self contained binary distribution". e.g. the Mozilla Firefox binaries.

/usr/local is for software you compile locally and install into a structure that matches /usr . The idea there is that your locally compiled version doesn't clobber the version provided by the OS. This is exactly how FreeBSD and OpenBSD ports are installed.

So I'm not sure installing packages into /usr/local makes any sense.

If I'm going to go to great lengths to package something, then I'm going to install it into /usr and I'm going to ensure dependencies are handled, and that I have correct conflicts in place to ensure I'm not overwriting anything. However I might not do any of the above, and we're back to where we were 10 + years ago with those user created Ubuntu packages which were frowned on by Debian users. This is why the likes of flatpak and snap appeared...

Otherwise I'm not going to bother packaging it in the first place.

clang is a compiler, i don't understand why it's there. It seams to be used to compile some scripts during normal use. You tell me what is for. Try with and without.

mariadb is an alternative database lib. it's probably libmariadb3 . It's probably already installed by something else. I suspect it's an alternative to sqlite. This could go in depends as 'libsqlite3-0|libmariadb3'. I think it's actually a drop in replacement for sqlite.

#suggests=('clang: Support for beautification of message filter scripts'
#            'mariadb-libs: Support for MariaDB-based data storage')

did you meant to say builddepends? suggests is the suggest in the binary package.

use this...

crappy easychroot, have low expectations. Will be polished over time. It's better over figuring out all the commands your self.
https://gitea.com/easydeb/easychroot

Thanks, will test it as soon as I find time for it.

The way I understand the debian policy guide "arch" should be "any" for rssguard: https://www.debian.org/doc/debian-polic … chitecture

I'm not a fan of git at all (in fact I find the syntax contrived, overly complex and unintuitive) therefore I don't really do git repos but maybe I'll get myself an account on gitea when I have more than one debbuild.

crappy easychroot, have low expectations. Will be polished over time. It's better over figuring out all the commands your self.
https://gitea.com/easydeb/easychroot

I updated the debbuild. It's "all" and priority was added in easydeb. Make an account on gittea, i'll make you a collaborator so that you can edit it your self in the future. branches correspond to debian distro that was tested on.

rssguard on the DUR https://gitea.com/DUR/rssguard

One run-time dependency was missing (now added) and I have done some other minor improvements, here is the latest version:

# Maintainer: LinuxTECH.NET <deb-packager{at}linuxtech.net>

pkgbase=rssguard
pkgname=(rssguard{,-lite})
pkgver=4.8.6
pkgrel=1.1
pkgdesc='simple, light and easy-to-use RSS/ATOM feed aggregator
 RSS Guard is simple, light and easy-to-use RSS/ATOM feed aggregator
 developed using Qt framework which supports online feed synchronization
 with these services:
  - [Tiny Tiny RSS](https://tt-rss.org)
  - [Inoreader](https://www.inoreader.com)
  - [Nextcloud News](https://apps.nextcloud.com/apps/news)
  - [Gmail API](https://developers.google.com/gmail/api)
 .
 .'
arch=(any)
control_fields+=('Section: contrib/web')
control_fields+=('Priority: optional')
url='https://github.com/martinrotter/rssguard'
license=(GPL-3.0-only)
depends=(libqt6widgets6
         libqt6gui6
         libqt6core6t64
         libqt6sql6
         libqt6sql6-sqlite
         libqt6xml6
         libqt6concurrent6
         libqt6core5compat6
         libqt6multimedia6
         libqt6multimediawidgets6
         libqt6qml6
         libqt6network6
         libqt6dbus6
         libstdc++6
         libgcc-s1
         libc6
         libsqlite3-0)
builddepends=(qt6-5compat-dev
              qt6-declarative-dev
              qt6-multimedia-dev
              qt6-tools-dev
              qt6-base-dev
              linguist-qt6
              qt6-webengine-dev
              libsqlite3-dev
              'cmake>=3.14.0')
#suggests=('clang: Support for beautification of message filter scripts'
#            'mariadb-libs: Support for MariaDB-based data storage')
source=(${pkgbase}_${pkgver}.orig.tar.gz::https://github.com/martinrotter/rssguard/archive/refs/tags/${pkgver}.tar.gz)
sha256sums=('c29bdda08ece8de113dbdb87e8e23491221ba9ddbacd26141d6a00e04888972e')

prepare(){
  cd "${srcdir}"
  mv ${pkgbase}-${pkgver} rssguard
}

build() {
  cmake -B build -S $pkgname \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DREVISION_FROM_GIT=OFF \
    -DNO_UPDATE_CHECK=ON \
    -DENABLE_MEDIAPLAYER_QTMULTIMEDIA=ON \
    -DENABLE_MEDIAPLAYER_LIBMPV=OFF
  cmake --build build

  cmake -B build-lite -S $pkgname \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DREVISION_FROM_GIT=OFF \
    -DNO_UPDATE_CHECK=ON \
    -DENABLE_MEDIAPLAYER_QTMULTIMEDIA=ON \
    -DENABLE_MEDIAPLAYER_LIBMPV=OFF \
    -DNO_LITE=OFF
  cmake --build build-lite
}

package_rssguard() {
  depends+=(libqt6webenginecore6
            libqt6webenginewidgets6)

  DESTDIR="$pkgdir" cmake --install build
}

package_rssguard-lite() {
  pkgdesc+=' This package contains RSS Guard without the WebEngine support.'
  conflicts=(rssguard)
  provides=(rssguard=$pkgver)
  replaces=(rssguard-nowebengine)

  DESTDIR="$pkgdir" cmake --install build-lite
}

It is actually very easy with easydeb too, I like the concept behind it, that you can simply share a debbuild file (which is essentially a recipe for anyone to automatically replicate your build, basically instead of sharing binary packages that could be many megabytes you just share a text file, which you can even share in a forum post like I just did, it's just text)  and how it has been implemented (that it's shell scripts).

Easydeb is 80%-90% there, it only needs a few more improvements (like the chroot build thing as already mentioned, in order to be able to get the build dependencies right) to become the best way to create packages for debian derived distros, I mean for anyone who is not planning to become an official debian dev (they have no choice but to package according to the debian rules).

well this thread if anything vindicates my refusal to create packages for anything i develop, less alone packaging for debian as it is an unnecesarely complicated crapshow or at least everything i've read so far has painted the creation of a new deb package from an upstream source that has not been previously packaged, admittedly i have not read the guide in the link shared by golinux but by this point i don't got high hopes.

Sure seems that way, at least to build an "official" package, I don't see myself doing that anytime soon. Sad thing is, it's really easy to do a simple package job with dpkg-deb. Place your scripts/files, control, postinst, build.

I didn't lol. I just build them on my user system.

I'm discovering the commands, i'll make a crappy script soon.

You just create a chroot, copy into it what you need, then enter the chroot as if you logged in an other linux machine and do your business. It's not too difficult to script. You are just the first person to care to do this. If you have a few packages, the manual way is fine, if you have 1000 like some distro maintainers, then yea, you'll need to automate.

you are using the wrong tool. translating it to a debian source package is overkill.

Ok, let me rephrase my question then:

What procedure did you follow to ensure that the build dependencies for all the DEBBUILDs that you created so far are complete and correct?

I couldn't reproduce, it ignores '()' as expected. But you are using _x86_64, it doesn't recognize the architecture so simply ignores it, it needs _amd64 . Is that the barf?

Also try using https://gitea.com/easydeb/pkgbuild2debbuild-helper-git . It's a good starting point, the dependency translation maps are just placeholders. Give me the dependency translations you are making, i'll add them. And expect bugs, this is brand new.

@EDX_0

easydeb is the packager for dummies. download a DEBBUILD from https://gitea.com/DUR that is close to your app and adapt it. I'll help if you get stuck. It's as accessible as possible. The DEBBUILD is a bash script that gets sourced, with intuitive variables and functions. The other two are doing weird things.

@tux_99

sbuild stands for source build, you are using the wrong tool. translating it to a debian source package is overkill.

the various commands of mmdebstrap seams to be what you need and maybe also schroot, and probably some commands from sbuild can be used.  I'm not familiar with this stuff. What you want could be done in a small script, just need to hunt down the commands. You are the first one that tries to do this...

I'll add Section sometime later. For now survive with  control_fields . Look how many they are, i plan on adding directly what people truly use, for the rest you'll be using control_fields.

Thanks, I think adding both "Section" and also "Priority" would be quite useful as these two are used and displayed by the Synaptic Package Manager for each package ("Section" to categorize the package and "Priority" is displayed in the Common tab of each package).
But yes, in the meantime the control_fields are good enough.

How in practice do you do that with easydeb in an easy semi-automated way?

To explain what I mean by "easy semi-automated way":
When you have a standard debian source package it's very easy to do a semi-automated build in a chroot.
It's basically just two commands, one for updating the chroot tarball of the base system (if it hasn't been updated recently already) and then launch 'sbuild' which will take care of creating the initial chroot, downloading the dependencies, building the binary packages and then cleaning up everything again.

To set up such a semi-automated chroot build environment I followed this guide which only needed a couple minor adaptations to work with Devuan:
https://stephan.lachnit.xyz/posts/2023- … cacher-ng/

As far as I see it there are two types of people to whom easydeb is aimed at:

- the simple user who just downloads a DEBBUILD file and then uses easydeb to build the package on his local machine with the aim to install and use it. This person has no need for a chroot build environment.

- the developer who want to create a DEBBUILD file that he wants to share with other users (for example via your git repo or the future DUR). When creating a DEBBUILD file meant to be shared with others the main issue (like with every package creation for any distro) is to ensure that the list of dependencies is correct and complete.

To make sure that the list of build dependencies is correct and complete AFAIK there really only is one way: by building the binary packages in a clean chroot freshly set up for each build with a minimal base system.

So IMHO it would be very useful for easydeb to create a standard deb source package in order to be able to take advantage of the mostly automated chroot build process that already exists for deb packaging.

Of course if there is an alternative similarly automated way to do such a chroot build directly with DEBBUILD files then there would be no need for easydeb to be able to create a standard deb source package, but if this doesn't exist yet then IMHO it would be easier to use the already existing sbuild chroot process rather than reinventing the wheel for easydeb.