Philip Brown <[email protected]> writes: > On 12/3/10, Peter FELECAN <[email protected]> wrote: >> This is an original way to say: if the features of a current product >> aren't complete and adequate do not use it. I don't think that in the >> real world that you like so much this is an acceptable attitude. Or is >> it? > > I think it is more accurate to say, "some 'features' cause more > problems than they solve, so adding every requested 'feature', is not > always the best path". > This is a very "real world" practical attitude, that most software > companies follow.
You speak from experience or just perusing a common preconception? >>> Or, just go with whatever the maintainer prefers as "top" priority, >>> and presume the user/admin will use the --set option if they have a >>> different opinion on order. >> >> In the original post the case was exactly what the maintainer wants: to >> set the same priority for a set of packages. What's different here? > > There is a difference. I describe "maintainer choosing a specfic order". > What you describe is, "maintainer refusing to choose a specific order". > Same priority == lack of order. > > another word for "lack of order" is "chaos", btw :) "chaos" is very often a misnomer employed by the unaware. >>> Order of install is often not an explicit priority-based choice, but >>> effectively random. So having a sticky selection based on "first >>> installed", is not a good policy. >>> User would be better served knowing with certainty, "if I have both >>> pkgA, and pkgB installed, then pkgB will ALWAYS get priority.. unless >>> I override with --set" >>> Rather than have to remember, "oh dont install pkgA, unless you've >>> installed pkgB first!" >> >> Well, in this case you lean toward deserving a part of the user >> base. > > > I did not understand your comment I mean that you propose a rigid behavior where a more flexible one serves better the user. By the way, I'm always wondering who's the real user of our work: the system administrator, the end user, Philip Brown, &c ? -- Peter _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
