Hi, I'm interested in your project and can bring some advice/help with the Debian packaging
of your application.
Disclaimer: I'm not a Debian maintainer but I've already read a significant amount of
the considerable of the documentation on this topic in the past.
I have packaged some projects for this purpose:
-
https://github.com/ysard/gatb-core/tree ... _packaging
- All GATB repositories and their debian_packaging branches
https://github.com/ysard?utf8=%E2%9C%93 ... ge=c%2B%2B
In order for this packaging to be done properly, the organization of the code needs to be somewhat rethought;
it may seem a big task but the benefit for the project is undeniable on the long-term. (in particular about its maintenance).
The main changes to be made will be:
- Splitting the program and its files into the standard GNU/Linux distribution folders.
Namely:
- binaries in /usr/bin;
- architecture-independent data (i.e. fonts/font2) in /usr/share/;
- logs in /var/log/
- data generated during the life of the program in /var/lib/
Note: Folders such as /home/pi/data can still be accessed via samba with symbolic links for example.
- The configurations in /etc/
Each task involves an unequal amount of work, but it is thanks to this that we do not lose our way from one distribution to another and that the programs are installed homogeneously.
- The configuration files should be managed by a library dedicated to this task.
Such libraries bring in particular:
- A single, centralized configuration file;
- Centralization of default settings in one place (this facilitates maintenance);
- Type-checking of parameters;
- Parameter sections.
I have in mind 2 light and very powerful libraries:
- libconfig: probably already installed on all systems.
- libconfuse: less complex but probably not installed by default
- We'll get at least 2 packages:
- a package dedicated to compiled binaries;
- a package containing the uncompiled, architecture-independent data.
Here are also some less urgent ideas:
- The compilation requiring the SDL should not be mandatory because it requires a lot of X server dependencies that users running in server mode (without a graphical desktop) don't need.
Therefore 2 versions of the binaries could be edited: with and without SDL support.
- A Systemd service could be used instead of the SysVinit service.
(although still supported for the moment).
As you can see the amount of work is consequent, especially for people who take their free time to make a project live (you may be part of it and therefore know as much as I do about this :p).
I come to a subject that is close to my heart and that I consider unavoidable;
have you thought about migrating your project under a free (or even open-source) license?
The arguments I put forward in favor of this migration are the following:
- Without access to a version manager, I can only help with the packaging in a very limited way;
- You lack the time to actively maintain both branches of the project;
(the public version
https://github.com/RWAP/PrinterToPDF/ and the undisclosed version);
- the backport of changes from one branch to the other is probably unfairly time-consuming;
- the public code and probably the private code need a lot of reviewing, testing... and a major hardening due to various bugs caused by the language used and the mass of code produced;
- you'll attract new and motivated developers to help, while keeping exclusivity on the hardware production line.
Given the number of users and programmers involved, older hardware probably has a greater need for FOSS and contributors than newer hardware, which de facto attracts a plethora of developers. As it stands, you may be missing out on a valuable work force.
It may seem unfair to release the sources for free when it's a huge amount of work, but in my experience, I think it's the best gift you can give to your hardware, your project, and all the people who still use the old hardware involved.
Thank you for your attention to this message;
Sincerely;
