[Debian-med-packaging] FW4SPL package

[Andreas Tille]

Hi Flavien,

On Wed, Nov 23, 2016 at 12:40:17PM +0100, Flavien Bridault wrote:
> Thanks again for your valuable help. I finally succeeded to build the
> camp and fw4spl packages. For fw4spl there is a big version bump, since
> I updated to 0.11.0.2. A major part of the patches in the previous
> packages were already fixed in this branch. So I removed some patches
> and updated other ones.

Sounds quite promising.
 
> Though, I have few questions left.
> 
> 1. I noticed in history that Corentin restricted fw4spl to "amd64" for a
> while and then he switched to "all". I think he was wrong and wanted to
> switch to "any" instead, am I correct ?

Yes, "any" is the correct architecture field.

> Then honestly, I can't ensure
> that fw4spl can compile and work on other architectures since we never
> tested it (we have an android build, so with arm, but it works with a
> complete different toolchain build). So I feel a bit embarrassed by
> letting this flag to "any" and then pray for the build to succeed. So I
> would argue to restrict to amd64. Do you have any advice ?

In principle it is correct to leave any.  Autobuilders will grab the
code and try to build - if the build fails there will be no package
created.  Sometimes you get patches from porters to make it build which
could be of some value for you as upstream.  A bad thing would be if
the package builds on some architecture but the resulting package just
does not work.  So some sensible test suite should be run (as well at
runtime - currently the test is disabled which is also not good - as
as autopkgtest for the installable package).

> 2. Lintian reports me some errors in fw4spl for each of the libraries we
> put in share/ :
> 
> E: fw4spl: arch-dependent-file-in-usr-share
> usr/share/fw4spl/activities_0-1/libactivities_0-1.so.0.1
> 
> I guess that this is because we are not supposed to put binaries in
> /usr/share.

Yes.  This belongs to /usr/lib/fw4spl.

> However this is an annoying case for us because we use the
> concept of "Bundles" that can be loaded at runtime, and inside these
> bundles, there is a mix of binaries and resource files. We could
> consider to split libraries and resources that so that instead of having
> this :
> 
> /usr/share/fw4spl/activities_0-1
> activities.xsd
> libactivities_0-1.so
> libactivities_0-1.so.0
> libactivities_0-1.so.0.1
> plugin.xml
> 
> we would have:
> 
> /usr/lib/fw4spl/activities_0-1
> libactivities_0-1.so
> libactivities_0-1.so.0
> libactivities_0-1.so.0.1
> 
> /usr/share/fw4spl/activities_0-1
> activities.xsd
> plugin.xml

Why not simply putting xsd and xml in /usr/lib as well.  Its not
mandatary that architecture indpendent files need to go to /usr/share -
but architecture dependant files need to go to /usr/lib per policy (and
FHS). 

> But this demand us to modify deeply our bundle loading code to support
> this. This is feasible, but maybe not immediately. Do you think the
> current situation is acceptable ?

Definitely not - simply move everything to /usr/lib.  If for some reason
some files need to reside in /usr/share you can use symlinks.
 
> 
> 3. I have the following lintian error:
> E: fw4spl source: source-is-missing
> Apps/VRRender/doc/source/_static/jquery.js line length is 694 characters
> (>512)
> 
> This file is present in the source but not used in the final package,
> shall I put it in "debian/missing-sources" ?

I'm not sure whether I understand the issue correctly.  It would be
easier to give advise if you would commit your current status to Git.
As far as I can see the best idea would be to rather Depend from package
libjs-jquery and use symlinks to the system provided jquery.  Except
there are very good reasons to use your own code copy I'd recommend to
do this.
 
> 4. I have not tackled the reopening of the bugs, could you please
> confirm that I have to do that through the mailing-list and then mention
> the bugs in the debian/changelog to close them ?

I admit I'm not sure if the bugs can be reopened for a not (yet)
existing package.  For simplicity I think its sufficient to add

   Closes: #bugnumber, #bugnumber

in debian/changelog for documentation reasons.  If the upload is
closing the bug and the bug was closed before that's OK IMHO.
 
> 5. Depending on your answer on the previous points, can I push my
> modifications on camp and fw4spl repos ?

Yes, please do in any case.  May be my answers would be even better. :-)
 
> Thanks a lot for your time and your advice. :)

Thanks to you for your cooperation

       Andreas.

-- 
http://fam-tille.de