Re: [MoM] Packaging mindthegap (Was: [MoM] Packaging mindthemap)
Hi Shayan,
On Fri, Jul 12, 2019 at 12:19:57PM +0100, Shayan Doust wrote:
> Hello Andreas & Andrius,
>
> That's great news. Thank you both for your time. Any other skill now
> mainly comes from time and experience.
:-)
> Running grep on upstream src with a search term of the misspelling, I
> can see that it is contained within at least one *.c. A patch could
> work, but I feel like it would fairly useless so either suppressing /
> ignoring the information or contacting upstream would do. I will
> probably just do some PR to correct this.
Fine.
> Thanks. I think it was at around 1 in the morning (a few hours after I
> sent my last email) that I realised dh_compress and the pattern of how
> files under doc had the tendancy of being compressed too while some
> other files were fine. Decompressing via gunzip also came into my mind,
> but I was reluctant as I didn't know if there would be another *hidden*
> method of calling something dh related.
You can add --exclude option to dh_compress like
override_dh_compress:
dh_compress --exclude=*.fasta
or something like this. I usually do this with PDF files since I do not
like that also PDF will be compressed. I think that would be another
solution for the problem - no idea what should be prefered finally. Since
the user has to copy that stuff anyway to run the example since /usr is
not writable it does not matter much, IMHO.
> I will further research on the
> steps that debhelper and package builders take which should be good
> reference for the future.
>
> I also assume that the architecture "all" would also work, for example,
> with header-only libraries that only require a straight-forward
> installation location.
Yes. (cimg-dev package is an example that comes to mind.)
> > I'm really happy that you managed in less than 10 days. Pretty good!
> > If you are interested in continue packaging something that might be
> > in your interest I'd happily support this.
>
> This first package has only gotten me more interested and invested
> within debian and debian med! I will of course maintain this in the long
> run with any upstream contact and any upstream updates and further
> patch-work expansions that are needed.
Great.
> Just a question regarding the next future package. Would softwares that
> fall under more of the neuroinformatic sector (even though theoretically
> medical related) be strictly suited for a blend like neuro-debian, or
> would this kind of overlap be perfectly acceptable within debian-med?
It does not make sense to draw a strict line between Blends like Debian
Med, NeuroDebian, DebiChem and may be others. So if you feel welcome
here are just a team member of Debian Med (=no need to ask for becoming
a member somewhere else) it is perfectly fine to maintain packages here
if these are "slightly related" to the Debian Med topic.
> Best regards & thanks to a "so-far-so-good" experience,
I admit I had a lot of fun with you as dedicated and fast learning
student.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: