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

[Juerg Haefliger]

On Tue, 20 Apr 2021 14:31:22 -0300
Thadeu Lima de Souza Cascardo <cascardo at canonical.com> wrote:

> On Tue, Apr 20, 2021 at 06:18:31PM +0200, Juerg Haefliger wrote:
> > 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  
> 
> Can you confirm that the problem with debian.master/abi/previous/ is only about
> the name, and there is nothing else about it?

Only the name.

 
> And what about the snippet I commented on, about doing a git-rm on any
> directory under ${DEBIAN}/abi/, but previous/? Does it become unnecessary after
> we migrate to this scheme and don't have any ${DEBIAN}/abi/{ABI}/ directories
> anymore?

I've replied to your other email but yes, it's no longer needed after the
switch.

...Juerg

 
> Cascardo.
> 
> > 
> >   
> > > 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/20210421/5d46138f/attachment.sig>