|Main Archive Page > Month Archives > fedora-users archives|
On 10/10/2011 11:16 AM, Rahul Sundaram wrote:
> On 10/10/2011 11:36 PM, JD wrote:
>> But that argues against your own argument that
>> a script will contain bugs. Of course it will - every
>> software ever written had them, and will have them.
> yes. so why is replacing one program with bugs with another script with
> bugs considered a solution? It isn't
Preupgrade is not a single operation solution. The
user is expected to know several complex operations
and execute them in right order.
A yum upgrade script would be a single point solution
that a user could run. If problems, then user could report
the results, along with a log file that a script could leave
behind. That is a very desirable solution for all non-techies
>> Also, you yourself said that upgrading via yum is
>> a very complex process:
>> > Upgrading a distribution is a fairly complex process to say the least.
>> So, by virtue of that statement itself, non-techies and
>> newbs most certainly need such an expertly written script(s).
> Scripts are not going to magically make things easier. Scripting is far
> more likely to be fragile as well. I didn't say yum upgrades are
> complex. I said upgrades are complex.
That is a very interesting opinion which ignores the fact
that scripts are easier to fix than binaries.
With so many scripts which are running the system,
then by your argument they should all be abandoned
because you opine that they are fragile and thus unreliable
and thus the whole system is unreliable.
Fear of possible bugs is no reason for rejecting a much needed
It seems to me that so many people invest so much steam
into their opinion, that they find it hard to back off and admit
that a proposed request for a solution is worth pursuing and
implementing by the experts in the field for the benefit of all.
-- users mailing list email@example.com To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines