This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wed, 2002-08-14 at 00:34, Nicholas Wourms wrote: > Robert Collins wrote: > > > What I mean to say is that, despite one's best efforts, compiled source > doesn't always behave as one had intended. Of course it will act as it > is written, it just may not seem apparent that the way it acts != the > way you intended it to act. Now that, that I agree with. > >Yes. And it should. You've also prodded me into finding a bug. Thanks. > > > Why is this behaviour considiered a bug? It seems quite logical to me. > It allows for the usage that Corinna had desired. Otherwise, there is > no way to garuntee that updating a package later in the alphabet won't > trump an earlier update's install. Pretty handy when you want to fix a > conflicting package f*$kup. Because it's actually worse. The cause of the conflicting package f***up is setup not checking for conflicts. So that can and will be addressed in other fashions. The reason to make upgrades atomic and done one package at a time is to deal with cases like the following: A pre-removal script (which *should* trigger on upgrades) may require binaries from another package being upgraded. Unless that other package is installed again at the time of the pre-removal script triggering, bad things will happen. Rob
Attachment:
signature.asc
Description: This is a digitally signed message part
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |