[b, c, d][PATCH v2] UBUNTU: [Packaging] buildinfo -- include origin package mark to modules files

[Seth Forshee]

On Mon, Feb 04, 2019 at 10:13:50AM -0200, Marcelo Henrique Cerri wrote:
> Sorry, I totally missed that one. Answers bellow.
> 
> On Mon, Dec 10, 2018 at 02:50:19PM -0600, Seth Forshee wrote:
> > On Wed, Dec 05, 2018 at 03:16:44PM -0200, Marcelo Henrique Cerri wrote:
> > > BugLink: http://bugs.launchpad.net/bugs/1806380
> > > 
> > > Include a flag at the end of each line of the
> > > "debian.$branch/abi/*/$arch/$flavour.modules" file indicating the
> > > package that each module is currently shipped in.
> > > 
> > > This will cause the build to fail when a module is silently moved from
> > > or to the linux-modules-extra package.
> > > 
> > > Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri at canonical.com>
> > 
> > Doesn't module-check also need to be updated to avoid breaking use of
> > modules.ignore? Or is the expectation that we will start appending the
> > "extra" as needed when adding modules to that file?
> 
> I believe so. Good catch. The kernels that I have tested do not use
> ignore.modules. I can update the patch with the fix to module-check.

Thanks.

> > 
> > I'm also curious whether you considered splitting them out into multiple
> > abi files, something like generic.modules and generic.extras.modules,
> > and if so why you settled on using a flag instead.
> >
> 
> Yes. My only concern about that approach is that we would multiple the
> number of files. Not a big problem. Do you see any benefits of having
> a separated file for that?

I don't think we should worry too much about whether or not it adds
files to the abi. I was more curious than anything though, I don't have
a strong opinion.

> 
> > Should we extract the flag name from the package name rather than
> > hardcoding it like you've done here. This may be overthinking it, since
> > I don't know whether we would need to track abi for any additional
> > module packages nor what those packages would be named.
> >
> 
> That can be done. However we already hard code the names of the
> packages we use to extract that information ("$(pkgdir_bin) $(pkgdir)
> $(pkgdir_ex)").

Ok, whatever makes the most sense.

Thanks,
Seth