Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Mar 2018 15:46:11 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-ports-bugs@FreeBSD.org
Subject:   [Bug 226611] KDE4_GENERIC_LIB_VERSION set to expected, not factual
Message-ID:  <bug-226611-13-fHNG4oEANi@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-226611-13@https.bugs.freebsd.org/bugzilla/>
References:  <bug-226611-13@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226611

--- Comment #8 from Mikhail Teterin <mi@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 B=
ug
196518, comment #5, where you stated -- without any evidence -- the same th=
ing:

> 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 t=
o 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 t=
he
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 sta=
te
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 an=
yone
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 suppor=
ter
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, tha=
nks
for letting us know" (with various degrees of priorities) or "this works as
intended".

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-226611-13-fHNG4oEANi>