search

rordenlab / MRIcroGL

v1.2 GLSL volume rendering. Able to view NIfTI, DICOM, MGH, MHD, NRRD, AFNI format images.
https://www.nitrc.org/plugins/mwiki/index.php/mricrogl:MainPage
Other
207 stars 33 forks source link

Debian installer #26

Closed neurolabusc closed 1 year ago

neurolabusc commented 3 years ago

@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.

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 commented 3 years ago

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

yarikoptic commented 3 years ago

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

ghisvail commented 3 years ago

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 commented 3 years ago

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

@ghisvail I have not seen Recommends before, thanks!

ghisvail commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago
  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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 2 years ago

@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.