Re: About fusioninventory-agent packaging
Hello Gregor,
I finished to review the TODOs and pushed the last commit with unstable in place of UNRELEASED.
Here are few explanations about the choices I did.
----- Mail original -----
> De: "Guillaume Bougard" <gbougard@teclib.com>
> Envoyé: Mardi 26 Juin 2018 10:20:36
> Objet: Re: About fusioninventory-agent packaging
>
>
> > > 5. the package doesn't build, a test fails:
> > > # Failed test 'rpm: parsing'
> > > # at t/tasks/inventory/linux/softwares.t line 306.
> > > # Compared $data->[6]{"INSTALLDATE"}
> > > # got : '24/03/2012'
> > > # expect : '25/03/2012'
> > >
> > > I don't have that issue on my own.
> >
> > I guessed so.
> >
> > > We had such kind of TZ related issue back in 2016 and it should has
> > > been fixed in 2.3.18. Can you give me more detail about which
> > > version is tested and in which context ? Eventually send me back
> > > the full output log so I can understand what happened ? Thank you.
> >
> > I built whatever was in git at that time, in my usual cowbuilder sid
> > amd64 chroot.
> >
> > I'm attaching my build log.
>
> Thank you, this should help to fix the issue... and add a patch :)
Well here I tried hardly in different context but I failed to reproduce the case.
Then to avoid losting more time, and as the failing test purpose was only to test the rpm command output parsing result which is definitively not relevant under debian, I decided to apply a patch to simply skip that test under debian.
> > 7. autopkgtest: the smoke test should run the same tests as during build; cf.
> > e.g. debian/tests/pkg-perl/smoke-skip and debian/rules in
> > libcatalyst-controller-html-formfu-perl
> > autopkgtest: the smoke test fails (should be better with the above
> > change); use.t is skipped -> needs debian/tests/pkg-perl/use-name .
> > for autopkgtest cf. https://perl-team.pages.debian.net/autopkgtest.html
>
> Okay, I'll follow your advices to fix that.
>
Indeed I failed here to find my way. I even tried to install some chroot to do the tests myself, but the https://perl-team.pages.debian.net/autopkgtest.html page seems completely outdated as few commands fail.
By the way, fusioninventory-agent being an application, FusionInventory::Agent module is not installed in the system perl library paths (this was historical and may change later). Then this makes the tests failing anyway.
So I just decided to remove the TestSuite field and I think fusioninventory-agent is not a good candidate for this test.
I hope this won't compromise the debian release and I understand it surely delays the merging in testing.
> > 11. you're removing conffiles (~ files in /etc), e.g. the initscript but also
> > the logrotate file and some cron stuff, maybe more. this requires a bit more: cf.
> > dpkg-maintscript-helper(1) (and rm_conffile there)
>
> Okay I'll do.
>
I added the needed snippet in d/fusioninventory-agent.postinst & d/fusioninventory-agent.postrm. I also added it in the new d/fusioninventory-agent.preinst. I hope I did it in the right way.
> > > 12. debian/rules: I think there's something to be simplified ... but we can look
> > > at that later :)
> > > I'm pretty sure the package doesn't build reproducibly because
> > > debian/fix-install.sh
> > > embeds the output of `uname -r' and `uname -n' which is a Bad Idea™
> > >
> > > Yes, I agree. My goal was to make it works, but surely not make it
> > > works cleanly. I'll pass some time on that to make it better. I
> > > even think I may have to enhance the Makefile.PL directly so every
> > > can benefit from the changes I need to do for debian.
> >
> > > To avoid mis-understandings in issue reporting with people from
> > > different platforms, we really need to set on which platform was
> > > packaged the software.
> >
> > Ok, I see the point.
> >
> > > Do you know what should I do to replace theses uname commands ? Is
> > > there any environment variables set by build environment I can
> > > simply use ?
> >
> > Hm, not sure, maybe someone else has ideas what to use in this case?
> > I guess the question is which information do you really need, and is
> > this information consistent across different debian builds.
> >
> > dpkg-dev has some makefile snippets that can be included in
> > debian/rules which provide variables that can be used:
> > Maybe $(DEB_VENDOR) from /usr/share/dpkg/vendor.mk is enough?
>
> Thank you, I'll check that, but I also think to see what I should better do
> in Makefile.PL to also limit the sources changes.
>
Here I decided to do all the requested work into Makefile.PL as this is not a debian only problem. So I added a patch I did upstream.
Then the d/rules file became really lighter.
This should also fix the package failing to build twice in a row.
I also added few line in d/rules to being able to set the version that will be reported by the script. I follow your advice and used snippet found in dpkg-dev examples.
Well, thank you for your help,
Waiting the next TODOs now ;-)
Cheers,
Guillaume
Reply to: