Debian installer

[neurolabusc]

@ghisvail, @mih, and @yarikoptic:

I am wondering if you can give me feedback on my first attempt at a Debian package. This uses your advice from this issue and attempts to copy your prior work with the neurologist-debian micron package.

• Experimental deb files are here, built using the script in the Debian folder of this repository.
• I want to provide both a GTK2 and QT5 release. What is the expected naming scheme? Here I use mricrogl_gtk2 and mricrogl. I realize that GTK2 is EOL, but GTK3 is limited to Core OpenGL support and is unable to support multi-sampling. I think that the QT5 widgetset should be the default, but I do not think this will work on older Debian releases (e.g. Ubuntu 18.04).
• Perhaps @dbannon can provide an update, but the QT5 version requires libqt5pas
  1.2.9, which I believe is newer than in Debian trunk. Previously, I have included release notes to use this version, but not sure how to capture that in a .deb file.
• As suggested by @ghisvail, the Python scripting will use the system libpython, rather than statically embedding a copy of Python. I specify Python 3.7 and greater. However, since a user might have several versions of Python installed, I am not sure what the right approach for identifying the preferred Python version to use. At the moment, I use the highest version number, but in theory a future version of Python 3 could remove a feature that breaks my software.
• My software will use dcm2niix if it is installed. If it is not installed, the Import/ConvertDICOMtoNIfTI menu item is not functional, but everything else works. If this is an option, should the Debian control file list dcm2niix in the Depends or not?

Any advice appreciated. This is my first attempt at supporting Debian and I would like to hear any wisdom you might have.

I appreciate any advice

[ghisvail]

Honestly, don't bother with GTK-2. It's more than deprecated at this point and Qt 5 is solid, stable and supported.

[yarikoptic]

Is ultimate goal to upload to Debian (and NeuroDebian) or just build/distribute .deb files?

[ghisvail]

but the QT5 version requires libqt5pas 1.2.9, which I believe is newer than in Debian trunk.

I guess NeuroDebian could provide it for older systems.

I am not sure what the right approach for identifying the preferred Python version to use.

The default Python 3 dev package is python3-dev and is a virtual package pointing at the currently supported version.

If this is an option, should the Debian control file list dcm2niix in the Depends or not?

Put it in Recommends instead.

[neurolabusc]

Ultimate goal is to upload to Debian. Perhaps @ghisvail can facilitate this.

@ghisvail I have not seen Recommends before, thanks!

[ghisvail]

In addition to Depends there are Recommends are Suggests. Depends is for hard dependencies, Recommends for soft dependencies providing important features, Suggests for soft dependencies providing non-essential features.

[yarikoptic]

Ultimate goal is to upload to Debian. Perhaps @ghisvail can facilitate this.

Then best to not bother with scripting it, but just have debian/ folder with necessary files populated.

[neurolabusc]

@yarikoptic I am pretty unfamiliar with Debian, so the script automates tasks like determining the version number and not including files specific to the Windows OS. The script does create a /debian folder, and then makes it into a .deb package.

@yarikoptic and @ghisvail I have tested the 1.2.20210831 deb files and they seem to work well on recent Debian releases (I tested back to Ubuntu 18.04, to ensure that everything works with Python 3.6).

1. How do we proceed on submitting this?
2. Do you want me to update MRIcron using the same structure? The version currently on NeuroDebian is pretty old (GTK2, vs QT5).

[ghisvail]

How do we proceed on submitting this?

I believe it will be best to start with the neurodebian builds. What do you think @yarikoptic ?

[yarikoptic]

1. How do we proceed on submitting this?

we can try -- prepare "source package" (.dsc and all files within accompanied by .changes file), upload to https://mentors.debian.net/ and give me a URL. For that:

The script does create a /debian folder, and then makes it into a .deb package.

instead of generating .deb with dpkg-buildpackage or alike, use dpkg-source . Then also run lintian command (from lintian package) on the produced .changes file. It should be "clean" ie not report any errors and ideally no warnings. If it does -- your scripts would need to adjust to produce a "valid" debian source packaging.

[neurolabusc]

@yarikoptic I know you are a Debian master, but can you break this down like you were describing this to a 5 year old kid. Is there an easy way to port data from the format expected by dpkg-deb --build to the format expected by dpkg-source, and what you would recommend for a dpkg-source call. I tried to create a changelog file based on what I could find online, but it did not like the format of my maintainer line. If you could provide an example or a clean tutorial that would help. The intricacies of the Debian methods are very unfamiliar to me. Is there a rationale for preferring the dpkg-source method - the step-by-step online tutorials I found all seem to use the dpkg-deb method, which seems to work for me.

[yarikoptic]

which tutorial you had in mind? The tutorial I am aware of is https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf

changelog has specific format it should adhere to for the packaging to be "proper" and so dpkg-changelog understands it etc. dch helper tool could be used to manipulate it from command line. E.g. we use it in our elderly backporting script: https://github.com/neurodebian/neurodebian/blob/master/tools/backport-dsc#L322 where based on original source package we provide one backported for a specific debian or ubuntu release (possibly with some extra patches applied).

treat dpkg-deb as the ld (linker) -- yes, you can use it to compose results of building individual components some way into a single executable or library. The point of debian packaging is to get "source package" so that anyone could rebuild it entirely (including individual components) and ideally across different architectures, to some of which yourself might not have access to. So for Debian (and NeuroDebian) it is important to prepare the "source package" which is pretty much "sources + makefile + extra metadata" (all under debian/, and well -- debian/rules is a Makefile typically ;)).

debian packaging/tooling carries lots of "organic growth" to it through over 2 decades, so it is not a surprise that many (myself included) are often lots and get allergy to it (e.g. conda-forge's approach is more succinct and "modern").

[neurolabusc]

@yarikoptic is the dpkg-source approach required for getting a package in a future release of Ubuntu and other Debian repositories, or can it be done with the dpkg-deb approach. My simple script can compile from source to multiple architectures (x86-64, PowerPC, ARM64), to multiple widget sets (gtk2, gtk3, qt5) using dpkg-deb. The dpkg-source approach seems to contain an awful lot of organic growth. For someone who supports multiple Ones, and various forms of Linux, leaner approaches are preferred if they are considered acceptable. I guess I am failing to see the benefit of the verbose source route if a simple script can create the .deb files for all targets.

[yarikoptic]

or can it be done with the dpkg-deb approach

it cannot be done for official upload to Debian (or NeuroDebian for that reason). I hear you that you would feel that using "home brewed" build process + dpkg-deb would be "leaner", but it would be "ad-hoc". If your build infrastructure is "standard", debian/rules would really be tiny, and the only "burden" is maintaining list of build and run dependencies and recommendations within debian/control. debian/changelog could be quite minimalistic in its verbosity if you have nice upstream changelog to ship along.

[neurolabusc]

@yarikoptic can you share the source folders created by NeuroDebian for mricron and micron-data so I can use them as a template (feel free to a google drive link of a compressed archive to my email address).

[yarikoptic]

mricron is maintained by debian-med now so it is available on https://salsa.debian.org/med-team/mricron/-/tree/master/debian (that is already the debian/ folder with all "debian packaging materials" which is just added on top of imported to branch upstream your source release).

from that single source package both mricron and mricron-data binary packages are produced. See https://salsa.debian.org/med-team/mricron/-/blob/master/debian/control which describes both.

[yarikoptic]

FWIW, on a debian system you can use debcheckout mricron to get a clone of the packaging repository (as specified in https://salsa.debian.org/med-team/mricron/-/blob/master/debian/control#L16) -- again harmonization across all packages so no need to 'google it up' for any particular one.

[neurolabusc]

@yarikoptic thanks for all your help. As a newbie, the Debian packaging details seem overwhelming. But at least each component is human readable and one can comprehend it bit by bit. This is much better than the Apple black box of code signing, specific app passwords, uploading, notarizing, and stapling where each stage generates the same vague error regardless of the specific nature of the error. It is never stated that changing your developer password routinely (which is a good security practice) invalidates any pre-existing app specific passwords as well, and the developer just gets a strange error that does not identify how to fix the problem (e.g. "The app specific password is invalid"). So please take my tone as inquisitive not hostile.

[yarikoptic]

So please take my tone as inquisitive not hostile.

oh -- I know that you are a good folk! sorry I can't really be of much help directly ATM to take on more "endeavors", but if you get some basic debian/ which does work for e.g. debian/rules binary for you (or a full dpkg-buildpackage -uc -us -rfakeroot invocation) -- I could have a look to help push it forward. Alternatively/complimentary you can reach out to debian-med team to help (take over) with packaging

[neurolabusc]

@ghisvail I have released a new version of MRIcroGL (v1.2.20211006). I have created .deb packages with control files that work with modern versions of Debian (tested with Ubuntu 18.04 and later). The code now automatically checks the folders expected by Debian for the application data as well as system versions of Python. I created a manual and other Debian details following the template of MRIcron.

Would you be willing to generate a proper Debian packaging for this? I realize you have a lot of other duties. However, I do think your expertise would aid this endeavor.

[neurolabusc]

@ghisvail I realize you are busy, but would be happy to collaborate to see MRIcroGL as a Debian package. I have tried to update the MRIcroGL code to be similar to MRIcron, but your encyclopedic knowledge of Debian installers would be a great help.