Re: [MoM] Packaging mindthegap (Was: [MoM] Packaging mindthemap)
Hello Andreas & Andrius,
That's great news. Thank you both for your time. Any other skill now
mainly comes from time and experience.
>> By "are these expected by mindthegap executable when running": Do you
>> mean whether or not they are used within a general runtime for any
>> command invoked by the user, as they are not.
>
> Yes, that's what I mean. Assume a user wants to analyse own data.
> Would this be possible without the files currently installed to
>
> /usr/share/mindthegap/data
>
> If the answer is yes, the files should rather go to mindthegap-examples.
> We want production packages with a minimum set of files that is needed
> for production. Anything else should go to some doc / contrib / example
> package (whatever name we might pick).
> ...
That makes sense. Good clarification.
> I: mindthegap: spelling-error-in-binary usr/bin/MindTheGap writting
> writing
>
> I have no idea how this is perceived. Sometimes I'm in the mood to
> fix even this - now idea about you (but its definitely no show stopper
> for an upload to new and thus I ignored this).
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.
> Users **should** lock into /usr/share/doc/PACKAGE - I know that this
> is hidden knowledge in practice but at least it is documented that all
> user oriented documentation and files that are helping the user to
> understand how to use the actual package can be found in
> /usr/share/doc.
> Users are not supposed to look into /usr/share/PACKAGE since there is
> rather technical stuff.
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. 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.
> 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.
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?
Best regards & thanks to a "so-far-so-good" experience,
Shayan Doust
On 12/07/2019 09:08, Andreas Tille wrote:
> Hi Shayan,
>
> On Thu, Jul 11, 2019 at 07:48:21PM +0100, Shayan Doust wrote:
>>> As an additional change: Please move /usr/share/mindthegap/test to
>>> mindthegap-examples may be to the dir
>>
>>> /usr/share/doc/mindthegap/examples
>>
>>> (or something like this) and adapt the test to this. I'm also
>>> wondering about the role of the data files in the dir data. Are
>>> these just examples as well or are these expected by mindthegap
>>> executable when running. If its the former these should also go
>>> into the examples package.
>>
>> By "are these expected by mindthegap executable when running": Do you
>> mean whether or not they are used within a general runtime for any
>> command invoked by the user, as they are not.
>
> Yes, that's what I mean. Assume a user wants to analyse own data.
> Would this be possible without the files currently installed to
>
> /usr/share/mindthegap/data
>
> If the answer is yes, the files should rather go to mindthegap-examples.
> We want production packages with a minimum set of files that is needed
> for production. Anything else should go to some doc / contrib / example
> package (whatever name we might pick).
>
> Assuming that this is the case all data should be carried in the package
> mindthegap-examples and there is IMHO the most visible directory
>
> /usr/share/doc/mindthegap
> ^^^
>
> Users **should** lock into /usr/share/doc/PACKAGE - I know that this is
> hidden knowledge in practice but at least it is documented that all user
> oriented documentation and files that are helping the user to understand
> how to use the actual package can be found in /usr/share/doc. Users
> are not supposed to look into /usr/share/PACKAGE since there is rather
> technical stuff.
>
> The additional advantage to move the architecture independent files out
> of the package mindthegap is that the architecture dependant package
> will cary mostly architecture dependant files. That's helpful for the
> mirror network since the data will be stored only once and not multiple
> times per architecture.
>
>> I now assume you meant
>> whether or not they are there solely as static reference or if they are
>> ever read and handled. Yes, they are read and handled by the test
>> scripts only, so I assume now I should just keep it where they
>> originally were and just keep test within the new path you specified?
>
> I think we now agree that all data can go to
>
> /usr/share/doc/mindthegap/examples
>
> and the run-unit-tests script is adapted to that location. However, you
> probably realised that the test is failing now. I checked this and one
> feature of dh_compress (which is called by dh - see dh_compress(1)) to
> compress files in /usr/share/doc if these exceed a certain limit. This
> means, before our test suite can deal with these data they need to be in
> the form as they were before (most files uncompressed but there is one
> compressed file expected (data/contig-reads.fasta.gz) to let all tests
> pass. I included this decompression procedure in my last commit.
>
>> Sorry about the confusion,
>
> No need to sorry. Its a feature of MoM that you can ask simple
> questions and make wrong assumptions etc. That's fine and I think we
> now sorted out everything. Thus I uploaded your package to new.
> Congratulations to your first Debian package!
>
> BTW, depending how picky you are you might like to contact upstream
> about
>
> I: mindthegap: spelling-error-in-binary usr/bin/MindTheGap writting writing
>
> I have no idea how this is perceived. Sometimes I'm in the mood to fix
> even this - now idea about you (but its definitely no show stopper for
> an upload to new and thus I ignored this).
>
> 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.
>
> Kind regards and thanks for your work
>
> Andreas.
>
Reply to: