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