Tias wrote:
> To resolve this I would like to propose a policy for `pear install` output:
>
> 1) Only show deprecated warnings of packages that are supplied as
> argument to the command:
> A user doesn't care that the package it uses depends on a deprecated
> package. The developer himself should be warned about this when packaging.
- this is probably a good idea except...
- can't contact the internet when packaging
> 2) Always install a dependency, even if its state is lower then the
> current preferred state.
> Once again, a user doesn't care what packages its software depends on,
> if you have to install every non-stable package by hand... then your
> scaring users away.
absolutely not. Stability is sacrosanct, particularly for large hosting
environments.
> 3) Show only one of 'Did not download (optional) depe...' and 'chan/pack
> can optionally use...' and show it only for packages that are supplied
> as argument.
How can you be sure that users don't want to see this? The "verbose"
flag is already available for filtering, have you tried setting it to 1
or to 0?
> 4) Do not download and install a package if one of its dependencies can
> not be installed.
I've tried to make it clear that this already happens, pearweb is indeed
not installed *or* downloaded - what happens is dependencies that *can*
be installed will be installed. Changing this will introduce a LOT more
complexity, which I am not comfortable with for one reason: it already
works.
This is a Pyrus and not a PEAR feature.
I love the way you're thinking, but as we learned from the last feature
iteration, even the smallest change to the core of PEAR can have huge
unintended consequences that break basic functionality. I'd prefer to
implement new features of this magnitude on a clean slate.
Thanks,
Greg
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
|