Bug 242077 - databases/ldb14: plist incomplete
Summary: databases/ldb14: plist incomplete
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Timur I. Bakeyev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-19 12:59 UTC by Dmitry Marakasov
Modified: 2020-01-14 00:58 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (timur)


Attachments
database_ldb14_Makefile.patch (887 bytes, patch)
2020-01-12 17:53 UTC, Phillip R. Jaenke
no flags Details | Diff
Same patch, not copy-pasted (650 bytes, patch)
2020-01-13 20:18 UTC, Phillip R. Jaenke
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Marakasov freebsd_committer 2019-11-19 12:59:03 UTC
...
====> Compressing man pages (compress-man)
===========================================================================
====> Running Q/A tests (stage-qa)
Warning: 'lib/python2.7/site-packages/tdb.so' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Warning: 'lib/python2.7/site-packages/_tevent.so' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Error: /usr/local/lib/libpyldb-util.so.1 is linked to /usr/local/lib/libintl.so.8 from devel/gettext-runtime but it is not declared as a dependency
Warning: you need USES+=gettext-runtime
====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: %%PYTHON_SITELIBDIR%%/_tdb_text.py
Error: Orphaned: %%PYTHON_SITELIBDIR%%/_tevent.so
Error: Orphaned: %%PYTHON_SITELIBDIR%%/tdb.so
Error: Orphaned: %%PYTHON_SITELIBDIR%%/tevent.py
===> Checking for items in pkg-plist which are not in STAGEDIR
===> Error: Plist issues found.
*** Error code 1

Stop.
make: stopped in /usr/ports/databases/ldb14


Full log: https://people.freebsd.org/~amdmi3/ldb14.log
Comment 1 Phillip R. Jaenke 2020-01-12 17:53:01 UTC
Created attachment 210661 [details]
database_ldb14_Makefile.patch

This is going on 3 months with no fix, and blocking 241347. Attached patch resolves fully, if not elegantly. Please commit ASAP on maintainer timeout.
Comment 2 Dmitry Marakasov freebsd_committer 2020-01-12 18:41:13 UTC
(In reply to Phillip R. Jaenke from comment #1)
The patch does not apply due to CRLF line terminators.
Comment 3 Timur I. Bakeyev freebsd_committer 2020-01-13 10:25:20 UTC
(In reply to Phillip R. Jaenke from comment #1)

If you need ldb 1.4 then you are doing something wrong.

The only valid Samba ATM is the Samba 4.10, which is dependent on ldb 1.5.

If you want to bring Samba independent dependency, then, please, use databses/ldb
instead.

This has to be cleaned up from the Samba 4.8 compatibility staff, but that's a different story.

By using ldb 1.4 you just again introducing conflict with Samba, just on another iteration. Please, don't do this.
Comment 4 Timur I. Bakeyev freebsd_committer 2020-01-13 11:04:29 UTC
(In reply to Phillip R. Jaenke from comment #1)

Moreover your patch is completely wrong, just brute forcing configuration that you happen to have, omitting all the system variables and breaking compatibility with Python 2.7+(which is questionably necessary now by itself) and Python3.

Your particular problem is easily resolvable by setting:

WITH_SAMBA4_PYTHON3=3.7

In the /etc/make.conf.

But again, I'm strongly dis-advise to use any ldb1[2-9] ports for SSD.
Comment 5 Phillip R. Jaenke 2020-01-13 13:30:19 UTC
(In reply to Dmitry Marakasov from comment #2)
Somebody needs to check Bugzilla there. I literally copy-pasted `cat the-working-patch` into the box.
Comment 6 Phillip R. Jaenke 2020-01-13 20:18:37 UTC
Created attachment 210717 [details]
Same patch, not copy-pasted

(In reply to Timur I. Bakeyev from comment #4)

You keep sending snippy 'send patches' responses to everyone - well here's a patch. This is tested and working in my environment with no issues; bugzilla mangled the patch - it happens. The patch is still valid. That certainly does not justify or warranty closing a valid bug, especially with incorrect information.

net/openldap24-[client,server] depends on ldb14 and will continue to depend on ldb14 for the foreseeable future, which impacts a further 124 ports. 

It should not require dragging portmgr@ in to deal with what is unquestionably a valid bug for what amounts to a 4 line fix that took me 5 minutes.
Comment 7 Timur I. Bakeyev freebsd_committer 2020-01-13 23:17:54 UTC
(In reply to Phillip R. Jaenke from comment #6)

> You keep sending snippy 'send patches' responses to everyone - well here's a
> patch. This is tested and working in my environment with no issues; bugzilla 
> mangled the patch - it happens. The patch is still valid. That certainly does 
> not justify or warranty closing a valid bug, especially with incorrect 
> information.

Patches are welcome, but correct patches, which do take ports infrastructure into account and variety of the system configuration options.

The provided patch just brute forced the state of your environment, without taking into account the presence or absence of Python 2 and Python 3 in the system.

> net/openldap24-[client,server] depends on ldb14 and will continue to depend on > ldb14 for the foreseeable future, which impacts a further 124 ports. 

It could be that I'm missing something, but I'd be VERY surprised if OpenLDAP depends on any version of LDB. The opposite is true, but who doesn't?

Can you, please, provide any confirmation of that statement?

So far I see only:

# pkg rquery %ro ldb14
security/sssd
security/sssd

Which is also a bug on my opinion, introduced by:

r505782 | antoine | 2019-07-03 21:30:03 +0200 (Wed, 03 Jul 2019) | 2 lines


> It should not require dragging portmgr@ in to deal with what is unquestionably > a valid bug for what amounts to a 4 line fix that took me 5 minutes.

The bug is valid, but should be obsoleted, as NOTHING should depend on any of ldb1[2-9] ports.

Alas, the mentioned above commit introduced that invalid dependency and now I have to deal with the consequences of this.

Rolling back to databases/ldb may not work properly, as database format has changed between the versions and downgrade is... Not supported.

Well, databases/ldb may become that moving target...
Comment 8 Timur I. Bakeyev freebsd_committer 2020-01-14 00:58:02 UTC
I guess the easiest solution for ldb14 would be to disable Python bindings completely, as they are not used(?) by SSSD and the given combination of Python3 enabled talloc/tevent/tdb and Python 2 bind ldb doesn't play well anyhow.

You can try to build port with NO_PYTHON=yes configuration option to see if that helps.