823217 - checksetup.pl should differenciate between a missing Perl module and an installed module which has a missing or broken dependency

Status: RESOLVED WONTFIX

(Bugzilla :: Installation & Upgrading, enhancement)

Description

[Terry Carmen]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121026113527

Steps to reproduce:

Ran ./checksetup.pl


Actual results:

Checksetup Said:
Checking for             DateTime (v0.28)     not found 
Checking for    DateTime-TimeZone (v0.71)     not found 

even though both were installed.



Expected results:

Should have recommended: perl install-module.pl Module::Runtime, which makes the above modules pass the test.

Installer needs to have Module::Runtime added as a dependency.

Comment 1

[Dave Miller [:justdave]]

This would be an upstream bug in those modules because their Makefile.PL files don't specify that as a dependency.  We can probably work around it by adding that as our own dependency in checksetup (wouldn't be the first time), but we should make sure it gets filed on CPAN's tracker, too.

Comment 2

[Frédéric Buclin]

This is not a bug in Bugzilla. It is a bug in the module not installing all its dependencies. If you installed these modules using your OS package manager, then report the bug to your Linux distro developers.

Comment 3

[Terry Carmen]

> This is not a bug in Bugzilla. It is a bug in the module not installing all its dependencies. If you installed these modules using your OS package manager, then report the bug to your Linux distro developers.

This was an install using the current version of bugzilla, downloaded from the website today.

The perl prerequisites were installed using the provided by checksetup.pl.

Regardless of whether the packages installed all their own dependencies, bugzilla incorrectly reported that packages were not installed, when in fact, they were. 

This lead to several wasted hours, searching Google, and turned up numerous people having the same problem, and eventually, one with an actual solution.

The easier fix would be to include the missing package in bugzilla's dependency list, since checksetup.pl did a good job otherwise, 

However it would be even better if checksetup.pl would report the broken dependency instead of issuing an incorrect error message about a package not being installed when it in fact, is. This would catch any future problems.

Comment 4

[Frédéric Buclin]

(In reply to Terry Carmen from comment #3)
> The easier fix would be to include the missing package in bugzilla's
> dependency list, since checksetup.pl did a good job otherwise, 

This is by far not the easiest solution. The list would be unmaintainable as everytime a Perl module on CPAN has newer dependencies, we would have to update our list too.


> However it would be even better if checksetup.pl would report the broken
> dependency instead of issuing an incorrect error message about a package not
> being installed when it in fact, is. This would catch any future problems.

This would make more sense. Updating the bug summary to reflect that.

Comment 5

[Terry Carmen]

Sounds good!

The only reason I opened the ticket is that it seems to be biting a lot of people.

Thanks,

Terry

Comment 7

[Dylan Hardison [:dylan] (he/him)]

This should not in the scope of what checksetup.pl does

Comment 8

[Terry Carmen]

checksetup.pl gives the user 100% incorrect information regarding a problem. It says that required packages were not installed, when in fact, they were installed.

Software that directly misleads the user is broken, whether you admit it or not.

If the installer can't give accurate information, at the very least it should tell the user "The installation failed but I don't know what the problem is." 

It's embarrassing to have software fail, then be deceptive about what's wrong.

Comment 9

[Dylan Hardison [:dylan] (he/him)]

I'd sooner have checksetup.pl be out (In reply to Terry Carmen from comment #8)
> checksetup.pl gives the user 100% incorrect information regarding a problem.
> It says that required packages were not installed, when in fact, they were
> installed.
I don't think this is still the case since I rewrote the dependency management code to use normal
perl mechanisms.

> Software that directly misleads the user is broken, whether you admit it or
> not.

I agree

> If the installer can't give accurate information, at the very least it
> should tell the user "The installation failed but I don't know what the
> problem is." 
> 
> It's embarrassing to have software fail, then be deceptive about what's
> wrong.

It is outside of the scope for Bugzilla to check if your perl setup is broken.

Note that if you're using OS-provided packages, and those packages are missing dependencies and are still somehow installed, that means that package providing the dependencies is broken (or at least, incomplete.)

If you don't use OS-provided packages, and instead use our 'cpanm' support
I don't think you'll run into this problem either.

Our new system also allows for (but doesn't yet encourage) the use of carton, which versions all the dependencies recursively:
http://www.modernperlbooks.com/mt/2013/07/brief-notes-on-managing-perl-dependencies-with-carton.html