install perl modules to perl vendor dir (namespaced)

[AdamWill]

os-autoinst installs its perl modules to pkglibexecdir. There doesn't seem to be any very good reason for this, and it plays havoc with Fedora's auto-provides and auto-requires; the package winds up both providing and requiring all this stuff:

perl(autotest)
perl(backend::baseclass)
perl(backend::console_proxy)
perl(backend::driver)
perl(backend::ipmi)
perl(backend::qemu)
perl(backend::s390x)
perl(backend::svirt)
perl(basetest)
perl(bmwqemu)
perl(commands)
perl(consoles::VNC) = 0.40
perl(consoles::console)
perl(consoles::localXvnc)
perl(consoles::remoteVnc)
perl(consoles::s3270)
perl(consoles::sshVirtsh)
perl(consoles::sshX3270)
perl(consoles::sshXtermVt)
perl(consoles::ttyConsole)
perl(consoles::vnc_base)
perl(cv)
perl(distribution)
perl(lockapi)
perl(mmapi)
perl(needle)
perl(ocr)
perl(testapi)
perl(tinycv) = 1.0
perl(tinycv::Image)

but it doesn't really provide any of those things, because other perl code couldn't find them in the standard way. Filtering out the provides is relatively easy (you can tell the auto-provides code not to generate provides from files in a given path), but filtering the auto-requires is much harder, I'd have to do it with a huge, fragile regex. I don't really want to turn off auto-requires entirely because, well, auto-requires are kinda good.

Shouldn't os-autoinst just install its perl bits to, well, the perl vendor dir, in the standard fashion? Is there any good reason not to? That would remove the need for the somewhat icky futzing about with @inc in iso2video, as well. Obviously, it'd make sense to 'namespace' all the modules, prefixing them with OpenQA:: I guess.

[AdamWill]

I guess this would also apply to the perl modules in openQA itself. Most of those are properly namespaced, but they're installed to a non-standard directory (datadir/openqa/lib). Again, is there any good reason for not installing them as standard vendor modules?

[coolo]

the argument is basically, openQA is an application not a perl module.

[coolo]

the same for os-autoinst. we want the tests to be simple - so we require our testapi. and not some library out of the system, hence no namespace.

[AdamWill]

well openQA and os-autoinst are applications, sure. but all the modules in them are...modules. Every time you call use foo, that's a module. I just don't see what placing all the modules in some private location actually gains anyone, and I can't find any references or documentation suggesting it's a good or common idea; all the information on how to do it tends to assume you want to do something else, like use a customized copy of a system module, or have parallel-installed 'production' and 'development' versions of a module, or something.

I'm no kind of perl monk, I'm willing to be wrong, but I'm not convinced yet ;)

[coolo]

well, what is the gain from namespacing every private module to the application?

[AdamWill]

The gain is that they follow the standard convention for loading modules, you don't have to futz around with @INC to load them, and things like automatic provides and requires work properly and don't potentially lead to problems if some other package decides to use the same vaguely generic module names...

I'm gonna ask the Fedora perl packaging team if this is something they've dealt with before and if there's a normal approach for it, too, just to cover the angles.

[AdamWill]

For the record, here's what our perl folks told me:

<contyk> 03:23:59> adamw: I'd go with the App:: namespace on CPAN
<contyk> 03:24:21> adamw: but of course, until they change it, you'll just have to filter all the private prov/req
<eseyman> 05:11:23> yes, it's frowned upon but tolerated
<eseyman> 05:11:35> and you have to filter out the requirements

so they agree that it's kind of bad, and point out that CPAN provides a namespace specifically for apps, but it is something that happens and if you really won't change it, I have to deal with it. So now I have a bunch of ugly regexes in my spec file. le sigh.

[coolo]

of course CPAN has a namespace for apps - but we don't want to be on CPAN.

[okurz]

Would anyone mind if we still add the App:: namespace?

[coolo]

App:: namespace is for App - see http://search.cpan.org/~spadkins/App-Context-0.968/lib/App.pm

Applications are not on CPAN - and you don't package apps like CPAN modules. We already started to add OpenQA:: to newly introduced os-autoinst classes to fix the namespace pollution. But installing application modules into library search path is wrong