[Bug 226611] KDE4_GENERIC_LIB_VERSION set to expected, not factual

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226611

--- Comment #8 from Mikhail Teterin <mi at FreeBSD.org> ---
(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.