Minimal version of Mail::Mailer

Vlad Dascalu vladd at bugzilla.org
Fri Feb 11 08:11:44 UTC 2005


David Miller wrote:

> The minimum version requested by the patch that introduced our 
> dependency on that module requires a version of the module that many 
> of the common packaging systems (Debian, Fedora, ppm, etc) are not yet 
> packaging.  The version was added only because that's the version the 
> author had on his system when he wrote the patch, and not because we 
> actually had a reason to depend on it.  This thread was an attempt to 
> try to find out what version we really need to require, rather than 
> just guessing at it, so as to avoid preventing people from upgrading 
> if they can't get the required version of Mail::Mailer.  These kinds 
> of specific things are very important for us to pay attention to in 
> order to improve our installation and upgrade experience, which is the 
> main thing most of our critics still complain about.

Most critics complain about the installation process. That is, about the 
fact that you must manually type a perl CPAN command line for each 
module you need.

The answer to that is not to reduce the number of command lines 
individually, by either reducing dependencies or their required version. 
Instead of chomping the "trees within the forrest" individually like 
that, we should look at the big picture and remove the whole manual 
command line installation process at all.

Besides the .rpm, which I think it represents a wrong direction, we 
still have the makefile thing to explore, as well as an automatic 
checksetup.pl that will ask the user: "Do you want checksetup.pl to 
automatically run for you perl -MCPAN etc? Warning: if you press Y to 
continue you must be logged in as root..."

This will allow us to automatically install what we are missing, and 
leave the users to resolve only those packages that produced errors.

This is an example of getting the big picture: watch the forrest as a 
whole; ignore the trees for a moment and think about how you could 
improve the system overall, in order to scale for future growth and needs.

"an attempt to try to find out what version we really need to require" 
is not "actually a good example of getting the big picture". It's an 
example where you try to fix the tree first without fixing the forrest. 
That is, an example of trying to solve one specific dependency without 
having a dependency automated install framework to begin with.

Vlad.



More information about the developers mailing list