The kdelibs on my system is of version 4.14.30. However, the PLIST_SUB in various KDE-related ports has settings like KDE4_GENERIC_LIB_VERSION=4.14.38 -- which reflects the version, that WOULD BE installed by the kdelibs port, were I to build it anew. As a result, ports like deskutils/kdeplasma-addons-kde4 fail to install -- because the plist is looking for things like libplasma_groupingcontainment.so.4.14.38 instead of libplasma_groupingcontainment.so.4.14.30. Instead of using hard-coded constants for KDE4_KDELIBS_VERSION and friends, Mk/Uses/kde.mk ought to query the currently-installed versions.
Hi Mikhail We only support one kdelibs verison at a time. Is there a reason not to update? mfg Tobias
(In reply to Tobias C. Berner from comment #1) > We only support one kdelibs verison at a time. That makes sense -- and I do have exactly one kdelibs installed on my system. It just is not the same version you have... > Is there a reason not to update? There may be a multitude of reasons for different people. The point is, the ports system should not create a new requirement. If a KDE-component is willing to build against an earlier version of kdelibs, FreeBSD ports should not require me to upgrade just to add this component. Consider the following likely scenario: 1. User installs a certain minimal set of KDE ports. 2. kde@ team upgrades the KDE-ports. 3. User updates his ports collection and attempts to add a KDE-port, which he did not have before. The upgrade of all of the already-installed KDE-ports must not be a requirement for the step 3 to succeed. This is the same "debate" we've had years ago regarding LIB_DEPENDS -- when various ports insisted on requiring a particular major shlib number. Fortunately, that debate is behind us. Unfortunately, KDE-team needs a refresher...
(In reply to Mikhail Teterin from comment #2) An update the the kdelibs ports may also require changes/patches to the depending ports. So there is no guarantee that a "current" kdelibs using port will build fine against an "old" installed kdelibs. So while it might build, it might package differently. If you want the ports tree at a current state, it's much safer check out that state. I'm not convinced this is a good idea, but the KDE-team is always open to patches :)
(In reply to Tobias C. Berner from comment #3) > there is no guarantee that a "current" kdelibs using port will build fine There is never a guarantee to begin with. However, currently, even when the new port does build absolutely fine, it fails to pack, because PLIST_SUB is incorrectly specified. That's a bug in FreeBSD ports system (Mk/Uses/kde.mk) and should be corrected before the next KDE upgrade is committed. > but the KDE-team is always open to patches :) I've raised awareness and now the healing can begin.
We absolutely DO NOT support having out of sync /usr/local and /usr/ports. When you update /usr/ports, you MUST update /usr/local.
(In reply to Mathieu Arnold from comment #5) > When you update /usr/ports, you MUST update /usr/local. This is certainly a change from FreeBSD practices of the past. Please, provide reference to this new policy being officially stated somewhere, as well as to the discussion, which lead to this change. Thank you.
This is not a new policy, this was always the case, you must update all your ports at once when you upgrade your ports tree, any other configuration is not supported.
(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".
I'd appreciate it if arguments over policies and procedures could happen outside a particular bug. As far as this one goes, tcberner@ in comment 3 has already said "open to patches", but it's fairly -- really -- low on the priorities list. Now, if the same affects KDE Frameworks 5-based ports, then we're more interested, but still open to patches.
(In reply to Adriaan de Groot from comment #9) I have always tried to take this same approach with the PR database. I would have said this first but you beat me to it. A mailing list would be a much more suitable forum.
Closing because the discussion doesn't seem productive (as in, producing a decision or results), using "Not enough information" because there doesn't seem to be a patch or a reference to a written policy that isn't being followed.
(In reply to Adriaan de Groot from comment #9) > I'd appreciate it if arguments over policies and procedures could happen outside a particular bug. ... (As well as in reply to Mark Linimon from comment #10) > I have always tried to take this same approach with the PR database Then both of you should've spoken to mat@, when he posted his claims. Once he did, I had no other choice but to challenge them, for they are obviously bogus -- even if it was not polite of me to point that out. > tcberner@ in comment 3 has already said "open to patches", but it's fairly -- really He did say that, but then a portmgr-member came out claiming this nonexistent policy. And, given that portmgr officially owns everything under Mk/, there is no point working up a patch while that body insists, things work as intended -- and thus, any patch will be rejected. It would be nice, if someone else from portmgr stated, that a proper patch will, indeed, be accepted once uploaded -- even if a proper repudiation of their colleague's bogus claims is too much to expect. > using "Not enough information" The amount of information supplied is perfectly sufficient -- everybody understands, what the problem is and how to reproduce it. > because there doesn't seem to be a patch Respectfully, that's not a good reason to close a PR...