ACK/cmt: [Unstable][PATCH 0/3] debian: Drop versioned ABI directory names

[Juerg Haefliger]

On Tue, 20 Apr 2021 08:04:44 -0300
Thadeu Lima de Souza Cascardo <cascardo at canonical.com> wrote:

> On Tue, Apr 20, 2021 at 09:59:00AM +0200, Kleber Souza wrote:
> > On 20.04.21 08:52, Juerg Haefliger wrote:  
> > > On Mon, 19 Apr 2021 14:59:41 -0500
> > > Seth Forshee <seth.forshee at canonical.com> wrote:
> > >   
> > > > On Mon, Apr 12, 2021 at 02:53:55PM +0200, Juerg Haefliger wrote:  
> > > > > We've talked about dropping versioned ABI directories in previous sprints
> > > > > but it never materialized. So here it is.
> > > > > 
> > > > > I'm not too crazy about the new name 'previous' but that's what it is
> > > > > basically, although there are new things mingled in like removed modules.  
> > > > 
> > > > Do we really need a directory named 'previous' at all? Or could the abi
> > > > files just be placed under $DEBIAN/abi directly? It would require a
> > > > different place to download the new abi, and we'd have to relocate or
> > > > remove the perm-blacklist file (but I can't remember it ever being used
> > > > anyway).  
> > > 
> > > I was thinking about this too but just changing the name and not the tree
> > > structure is the simplest first step. Getting rid of 'previous' can be a
> > > follow-on cleanup.  
> > 
> > Currently there are two directories defined in 'debian/rules.d/0-common-vars.mk'
> > and the current one ("abidir") seems to be used only in
> > 'debian/rules.d/2-binary-arch.mk' to build the files that are going to be
> > shipped by the buildinfo package. The path itself doesn't seem to be relevant,
> > so we could easily place them somewhere else when 'previous' is gone.
> >   
> 
> Which is just bikeshedding, isn't it? We have two paths, one where we keep the
> files that correspond to the expected ABI or the ABI that corresponds to the
> latest/previous/old build. The other path is where we put the files
> corresponding to the current build, which we: use to compare against the old
> one, use to ship in the buildinfo package, so we can then put it into the other
> path.
> 
> So, it feels to me that having debian.master/abi/previous/ vs
> debian.master/abi/, and debian.master/abi/current/ vs debian.master/tmp/abi/ is
> just bikeshedding.
> 
> If this is about the fact that we treat some files differently, like the
> modules file, which should always match the current build and must be kept
> updated every time we change config files, whereas the abi symbol files is only
> compared against if we didn't change the ABI, I think just the fact that the
> path is now kept stable, is sufficient to solve the problems we have, whenever
> we rebase or respin before/after applying these modules changes.

So is that an ACK then?

...Juerg


> Cascardo.
> 
> > 
> > Kleber
> >   
> > > 
> > >   
> > > > What you have is fine with me though, just a thought if you really want
> > > > to get rid of the 'previous' directory.
> > > > 
> > > > Acked-by: Seth Forshee <seth.forshee at canonical.com>  
> > > 
> > > Thanks for the review.
> > > 
> > > ...Juerg
> > > 
> > >   
> > 
> > 
> > -- 
> > kernel-team mailing list
> > kernel-team at lists.ubuntu.com
> > https://lists.ubuntu.com/mailman/listinfo/kernel-team  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20210420/ba38e1fe/attachment.sig>