https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226611
--- Comment #8 from Mikhail Teterin <[email protected]> --- (In reply to Mathieu Arnold from comment #7) > this was always the case Not only is the above statement not true, you, Mathieu Arnold, _know_ it to be untrue. One proof is in your Bug 114167, comment #4, dating back to 2014. That entire PR was filed to handle the situation, when an already installed shared library has a major number different from what the latest version of its port installed. The change I proposed in 2007 eventually got rejected (in 2012), because of all the work, that's gone into removing the unwarranted shared-library major numbers from the individual ports. Had the policy you claim to have "always" been in effect, actually been in effect, that "major effort" -- as eadler@ called in Bug 114167, comment #2 -- would not have been necessary and my proposal would've been rejected much sooner. And, of course, various ports as well as bits under Mk/, make an effort to work with different versions of dependencies -- examples abound, just look into Mk/Uses/compiler.mk for one... Now, I'd be willing to give the benefit of the doubt to a fellow FreeBSD committer, but this is not the first time you assert this policy "always" having been in place, which is a demonstrable untruth. I refer now to the Bug 196518, comment #5, where you stated -- without any evidence -- the same thing: > We do not support partial upgrades, never had, never will. Though I asked you to substantiate it back then, you never did. Now that any reasonable reader is convinced, the policy you are referring to as "always there", was not in place even in 2012, I ask you again: . What -- other than your own imagination -- makes you believe, it exists TODAY? A link to Handbook would be helpful here. . Where can one find the archive of the discussion, which resulted in the policy being accepted by FreeBSD/portmgr (some time in or after 2012)? If the mailing list is closed to mortals, a statement identifying just the dates, when the discussion took place, would suffice. And if you can not convincingly address the above bullet-points, kindly state for the record, that you made a mistake and the policy you THOUGHT was in place, in fact, is not. I'd really hate to repeat this conversation with anyone for the THIRD time 3 years later... > any other configuration is not supported. The entire "not supported" line is completely meaningless in the context of a volunteer open source project -- this too is something I told you in Bug 196518, comment #9. The "we don't support that" line is for people working under commercial Service Level Agreements (SLAs), where the would-be supporter owes MONEY to the supported, if they can not adequately fix a problem within specified time. In a volunteer-based project there are neither "guarantees" nor "not supported". There are only "this is a problem that should be addressed, thanks for letting us know" (with various degrees of priorities) or "this works as intended". -- You are receiving this mail because: You are on the CC list for the bug.
