Re: Sponsor for DMX - The Context Machine
Juergen Neumann writes:
> Hi all!
>
> I would like to file an ITP for DMX - The Context Machine [1], formerly
> known as DeepaMehta [2]. As this will be my first project for Debian I
> am kindly looking for a sponsor. So far I barely managed to create a
> first lintian compliant result [3]. I will be happy to improve. :-)
>
> Thank you very much in advance!
>
> Juergen
>
> [1] https://git.dmx.systems/dmx-platform/dmx-platform
> [2] https://www.deepamehta.de/
> [3] https://github.com/dmx-systems/dmx-build-deb
Hello Juergen,
I'm still quite new to Debian packaging and certainly can't talk for
the Debian project but I'll try to give you some advice nevertheless.
I hope the following advice is correct Debian-wise; sorry if I'm
making mistakes, please correct me in that case.
I can see in the README of dmx-build-deb:
dmx-build-deb builds Debian packages from DMX binary files and
loads them into the public repository at DMX Systems.
Debian packages normally build software from source, not binary. That
is required for your package to be part of Debian proper (the "main"
section). If that's impossible though, there is the "contrib" section
where such packages can be uploaded. It is recommended to build from
source whenever possible.
Also, I guess a Debian package should not load anything to some other
repository.
Your debian/README.source is basically a template. You should either
remove it or write something interesting there. README.source is the
place where you document specifics of your package with regards to how
it should be built.
debian/control, debian/copyright are templates (@@PACKAGENAME@@,
@@CONFLICTS@@, ...). It looks like it is instantiated through
.gitlab-ci.yml. I guess it is OK in principle, but remember that you
have to upload a Debian-compliant source package in any case.
I'm not sure whether a Debian package can be named "dmx-latest"; I
guess it should just be named "dmx".
Debian takes copyright and license information very seriously; if
there is any doubt on the license of some file, it might need to be
removed from the set of packaged files through a +dfsg modification.
Therefore it is highly advised that the license of each source file in
the upstream source code be very clear. The safest if you can is to
add to each nontrivial source file the copyright line of each
contributor with the years of contributions, and indicate which
license applies to this file (and in particular if it is AGPL3 strict
or "AGPL3 or later"); this is the case for the GNU project. Many
projects don't do that, which may make it more difficult to be
uploaded to Debian (sometimes a little more, sometimes a whole lot
more). The clearer the better, and as a bonus it saves a lot of time
to the people who are in charge of verifying the license of the
software: if you can do that then that's the best; if not, try to be
as clear as possible and cross fingers.
It is not mandatory, but it is possible to format debian/copyright
with a machine-readable format [1]
It would be nice to also produce a "-doc" package containing the
documentation [2], so that people with internet connectivity issues
can still read the documentation.
Through .gitlab-ci.yml you auto-generate debian/changelog. I doubt an
auto-generated changelog can be used if you want your package
integrated in Debian: end users should be able to modify your package
at will, and add what they want to the changelog.
In debian/postinst it looks like a password is stored into
/etc/dmx/config.properties, but I don't see any provision (such as
umask 077) to make sure it is not world-readable before "chmod 750
/etc/dmx". For you to check...
debian/rules contains comments from the template; you should probably
clean them up.
I don't know debconf, but at what point is the equality between
dmx/initial_admin_password and dmx/initial_admin_password_again
checked?
Once you have built the source package and the binary package(s)
locally, you should run "lintian -EviIL+pedantic" to see if you have
any important things to fix.
One of the first things you need to make clear is how you want to
create your package(s):
- By building the upstream source (main)? By packaging the upstream
binary (contrib)?
- How do you organize the packaging files and your workflow for
creating packages: with origtargz(1), uupdate(1), git-dpm,
git-buildpackage, something else...?
[1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
[2] https://dmx.readthedocs.io/en/latest/
Hope this helps!
Best regards
--
Fabrice BAUZAC-STEHLY
PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Reply to: