Re: Missing @INC path for pkg-perl-autopkgtest
Hi,
thank you all for your very valuable feedback!
On Sa, 25 Okt 2025, Alex Muntada wrote:
> I can't really comment on the autopkgtest issue, but I'd like to
> explain how to avoid collisions on filehandle E:
> ```
> local *E;
> ```
Okay, did so.
> Or replace E with a scalar filehandle (e.g. $env_fd)
I tried to follow the style of this existing script and it used the
old style filehandle.
On Di, 28 Okt 2025, Niko Tyni wrote:
> I wonder how much the pkg-perl-autopkgtest scripts should bend to
> cater for other use cases than standard CPAN modules.
chordpro is at least a CPAN package, containing some CPAN modules
(App::Music::ChordPro) and also applications (chordpro and wxchordpro)
that use these modules.
Since this all is on CPAN, using the standard CPAN mechanisms seems to
be the right way for me.
> That said, you (Roland) might want to consider
> /usr/share/chordpro/lib or something like that.
I'll think about this and have a look how hard it is to do so, since I
currently just follow the way this is implemented upstream by the CPAN
author. He places some "local" stuff in /usr/share/perl5/ChordPro/lib
and /usr/share/perl5/ChordPro/res. But at the moment I don't have an
idea how to move these directory without breaking the complete package
(or moving and restoring the original locations using symlinks, which
wouldn't be a big win).
Would moving the files out of /usr/share/perl5 imply that the
pkg-perl-autotest stuff ignores them? From my point of view this
would be a step back, since testing the perl modules with some of the
standard mechanisms sounds as a good idea to me in any case, even if
they are only used locally by the chordpro application.
> I don't see much point in installing modules under the normal
> "public" search path while making them undiscoverable with an extra
> subdirectory. Having them under /usr/share/chordpro would make it
> clearer that they are private.
I agree, but it's tricky for me to implement this, since this isn't
the way the upstream author has planned how it works. So if I find a
way to move the files, I'll also have to make sure, that the modules
and applications still find them there, without otherwise break them.
I'm not sure, whether this is worth the effort.
> On Sun, Oct 26, 2025 at 03:21:05PM +0100, gregor herrmann wrote:
> > Not sure if we want a specific debian/tests/pkg-perl/syntax-env or
> > a generic debian/test/pkg-perl/{set-,}env for all tests …
>
> I think a separate file for each test helps keep track of what's
> needed for what. It's not like that's going to lead to much
> duplication anyway. Obviously consistent naming would be nice, as
> far as possible. So I guess debian/tests/pkg-perl/syntax-env would
> be my preference given the existing names.
So I'll push my "extension" of pkg-perl-autopkgtest evaluating
syntax-env to the salsa repository.
Since I'm waiting with the upload of the next chordpro release for
this change, is it okay to prepare a release of pkg-perl (as a team
upload) or should I wait and let this be done by one of the already
listed Uploaders?
Greetings
Roland
Reply to: