Member


profile-image

TheBlackCat

Todd R
No supported products.
39 comments
KDE ePub Thumbnailer Various KDE Extensions
May 04 2014
yaWP (Yet Another Weather Plasmoid) KDE4 Extensions
May 16 2013
yaWP (Yet Another Weather Plasmoid) KDE4 Extensions
May 15 2013
yaWP (Yet Another Weather Plasmoid) KDE4 Extensions
May 15 2013
Panel Toggle KDE4 Extensions
Feb 27 2013
Smooth Tasks 2 KDE4 Extensions
Mar 06 2012
PublicTransport KDE4 Extensions
Nov 04 2011
PublicTransport KDE4 Extensions
Oct 24 2011
PublicTransport KDE4 Extensions
"Isn't it always like this?"

Usually in cases where the library and other components live in the same tree, the library and other components can be built in one go. Then the libraries are split up from the other files using sub-packages after the build is complete. I am pretty sure both RPMs and DEB files support build multiple packages from a single package description file (I know RPMs can).

The advantage of this is you can have clean separation of the shared library and non-library rpms or debs while only needing a single tarball, a single package description file, and a single build.

The same is true of localization files. These are almost always built with the rest of the software and then split off using automated scripts that search for the language files, tag them with the appropriate language data so users can find them, and put them where they need to go (either in the main package or in their own package, depending on how big they are). This is one of only two pieces of software I know of that expect users to download, tar, and build the language files separately.

So as it is now, it is very difficult to package. The stuff that you are having packagers do by hand is usually done automatically after the build using package description files.

For most package you just drop in a tarball, change the version number, then start the build. With this package you have to manually do multiple individual steps using a GUI interface. That make it easier for users at home building for themselves, but much harder for packagers. If you would like I could provide a spec file to show you how, at least for RPMs, software like this is usually structured.

In my case it is even more difficult because I am using open build service, which can be set up to automatically download the latest git snapshot, update the version numbering, build the package, and publish it with a single button press. This is ideally-suited to software like yours where the master git branch is always stable. But because of how the package is structured, this is impossible. Especially with how the language files are divided up in separate directory trees that all have to be downloaded separately, it is impossible to automate the build process. Currently I am just not building the language files.
Oct 23 2011
PublicTransport KDE4 Extensions
Oct 23 2011
PublicTransport KDE4 Extensions
Oct 20 2011
Oxygen KDE (Firefox Theme) Various KDE Extensions
Oct 04 2011
Oxygen KDE (Firefox Theme) Various KDE Extensions
Aug 09 2011
PublicTransport KDE4 Extensions
Jul 25 2011
Sea Plant Wallpaper Other
Jul 12 2011