[apparmor] Deprecating the Perl bindings?

[John Johansen]

On 9/8/21 12:13 PM, Christian Boltz wrote:
> Hello,
> 
> Am Dienstag, 7. September 2021, 08:50:27 CEST schrieb intrigeri:
>> As far as I can tell, in the upstream code base, aa-notify was the
>> only thing that depended on the Perl bindings to libapparmor.
>> It's been ported to Python so that's not the case anymore.
>>
>> With my Debian hat on, I can say that shipping the Perl bindings
>> (libapparmor-perl) makes some stuff more complicated, for example for
>> adding cross-building support. So I'm considering dropping them:
>> https://bugs.debian.org/993565
>>
>> What would be the drawbacks of dropping the Perl bindings upstream?
>>
>> Are we aware of code that uses them? In openSUSE tooling, perhaps?
> 
> Historically the YaST2 AppArmor module used the perl bindings (and even 
> the old perl modules), but since several years YaST is baiscally a 
> graphical frontend to   aa-genprof --json   etc. - and that way solved 
> more than one problem. I was even able to do a "remote bugfix" to YaST 
> by fixing something in aa-genprof ;-)
> 
> I'm not sure if other packages use the perl bindings (unfortunately I 
> can only easily find out what depends on AppArmor, but not individually 
> for the perl-apparmor subpackage). At least on my laptop, I could 
> uninstall perl-apparmor without complaints.
> 
>> Are we confident they'll keep working, even though we don't actively
>> use them upstream anymore?
> 
> Well, we didn't get any bugreports ;-) which can mean
> - it works
> - nobody uses it   or
> - it's broken and nobody uses it
> 
>> If we want to drop them upstream, what would be a suitable deprecation
>> process and timeline? Would it be sufficient to announce this on this
>> mailing list and drop them in the next major release?
> 
> As long as it doesn't case lots of work, I'd tend to keep the perl 
> bindings upstream. This is not a strong vote, so if we want to add a 
> deprecation note (so that we can say "told you so" whenever the perl 
> bindings cause us headaches), I'm also fine with that.
> 

As an upstream we are very slow to drop things, and as a general rule
we have to go through a deprecation process. So the perl binds aren't
going to be dropped at least in the short term.

We can certainly start the discussion of whether they should be deprecated


> At the same time - if the perl bindings cause you major headaches on 
> Debian, feel free to drop --with-perl.
> 

yes, this is the immediate solution for debian. And we can take that
as a data point for the deprecation discussion.