#4487 lmdb1-0.9.14 and lmdb++-0.9.14.0

[Arto Bendiken]

Please find attached two interrelated package submissions: one for the LMDB database engine (http://symas.com/mdb/), and another for its C++ wrapper interface (http://lmdbxx.sourceforge.net/).

I confirm that I've read the Packaging Manual, have run fink validate on the .info and .deb files, have run fink -m rebuild, and have attached the dpkg -L output as a text file.

[Arto Bendiken]

The .info and .patch file defining the lmdb1, lmdb1-dev, and lmdb1-shlibs packages. [corrected]

[Arto Bendiken]

The .info file defining the lmdb++ package. [corrected]

[Alexander Hansen]

Thanks for the submission.

It builds for me on 10.10.

You can get rid of the BuildDepends: fink (>=0.24.12)--I can't imagine that somebody will try this on a platform which can't use fink-0.30.x at the oldest.

[Arto Bendiken]

Thanks, will do. I had defined that because of the wording at http://fink.thetis.ig42.org/doc/packaging/reference.php?phpLang=en:

"Any package that uses PatchFile must declare at least BuildDepends: fink (>= 0.24.12)."

[Alexander Hansen]

That's outdated at this point. It doesn't hurt anything to have it, but it's not really required any more and the fink validator doesn't check for this.

[Daniel Macks]

In lmdb1:

Suggests: %N-dev (= %v-%r)
Recommends: lmdb++ (>= %v.0)

looks wrong. Why would one want or need static libraries and/or headers in order to run the mdb_* utility programs?

And lmdb++ is just a header, no actual library, so it presumably would be BuildDependsOnly:true (when else would one use a header except at the compile-time of some other package?). And Depends:lmdb1-dev also probably seems philosophically correct, but it's technically not. Even though I assume lmdb++.h has #include for lmdb.h, it's up to whatever package would use BuildDepends:lmdb++ to also have BuildDepends:lmdb1-dev. Headers packages aren't allowed to have runtime dependencies on each other because they don't actually have a "runtime", but also because doing so creates a hopeless deadlock for users if the lower-level library gets updated in certain ways...the exact situation that having separate -dev and -shlibs packages aims to prevent.

[Arto Bendiken]

Thanks, will correct. These aspects of packaging were the hardest to wrap my head around. I spent much time trying to grok the implications of the shared library policy but clearly will need to re-read it a few more times ;-)

[Daniel Macks]

In lmdb1, what's the purpose of "Provides: lmdb"? Are there other packages other than this one that supply those same mdb_* utility programs? Or is it future-proofing against a new version that might be called lmdb2? In that latter case, the package itself may as well be named "lmdb" directly.

[Arto Bendiken]

The purpose was to provide a "virtual package" for the proper name of the software. I would be happy to rename the package to plain "lmdb" instead of "lmdb1", but had been going by the (possibly outdated?) policy at http://fink.thetis.ig42.org/doc/packaging/policy.php?phpLang=en#sharedlibs:

"Each software package for which public shared libraries are built must have a major version number N, which is included in the shared library's filename (for example, libbar.N.dylib). The major version number is only supposed to change when a backwards-incompatible change in the library's API has been made. Fink uses the following naming convention: if the upstream name of the package is bar, then the fink packages are called barN and barN-shlibs. (This is only strictly applied to new packages, or when the major version number changes.)"

[Alexander Hansen]

That's for the libraries and build-time (headers etc.) files. User executables aren't required to use the lib version, though it's allowed.

[Arto Bendiken]

OK. Sounds like it might be a good idea to rename, then. Just to confirm, I'd do the following:

• Rename the "lmdb1" package to plain "lmdb".
• Keep "lmdb1-dev" named as it is.
• Keep "lmdb1-shlibs" named as it is.

Any other issues to address before this looks good to you guys?

[Arto Bendiken]

Ping?

[Alexander Hansen]

Sorry about the delay, I've been really busy.

Yeah, that should be OK.

[Arto Bendiken]

Alexander and Daniel, thanks for the review. I've attached new versions of the package files, with the following corrections incorporated:

• lmdb1.info: Dropped the BuildDepends: fink (>= 0.24.12) directive.
• lmdb1.info: Dropped the Suggests: %N-dev (= %v-%r) directive.
• lmdb1.info: Dropped the Recommends: lmdb++ (>= %v.0) directive.
• lmdb1.info: Set BuildDependsOnly: True for lmdb1-dev.
• lmdb++.info: Added a BuildDependsOnly: True directive.
• lmdb++.info: Dropped the Depends: lmdb1-dev directive.
• lmdb*.info: Added a DescPackaging section with a link to this ticket.
• lmdb*.info: Bumped Revision to 2 to facilitate testing for anyone who already installed these packages.

[Arto Bendiken]

Alexander and Daniel, I've now attached what I hope are the final versions of the package files, with the following corrections incorporated:

• lmdb.info: Renamed the main package from lmdb1 to lmdb.
• lmdb.info: Removed the Provides: lmdb directive.
• lmdb*.info: Set the Revision: 1 directive in prep for commit.

Also, have attached the updated dpkg -L output.

[Arto Bendiken]

Ping? I believe this has been ready to commit for the past two weeks.

[Alexander Hansen]

I don't think this tracker allows you actually to update files in a post. I got the same versions.

Try attaching the new.info (and .patch if needed) to a separate post.

[Alexander Hansen]

As I said, we don't have the new package description files. Otherwise, I'd add them.

[Hanspeter Niederstrasser]

These two posts say they were edited on May 10, 2015. Are the .info/.patch files attached to them the updated pkg files? I don't see any of the issues that dmacks and akh pointed out left in them. However, lmdb.info from that first link has lmdb1-shlibs::Provides: lmdb-shlibs and lmdb1-dev::Provides: lmdb-dev. There's no reason for numbered -shlibs or -dev packages to Provides an unnumbered package.

[Alexander Hansen]

I was going by the "bumped revision to 2" from 4/28.

Providing an unnumbered package is the wrong thing to do for a library, because it circumvents our shared library policy.