Update sqliteodbc ports and merge slave port as a flavor
AbandonedPublic
Actions

Authored by madpilot on Jun 14 2020, 1:05 PM.

Details

Reviewers

None

Group Reviewers

portmgr

Summary

While updating databases/sqliteodbc I'd like to merge the sqlite2
version slave port as a flavor of the sqlite3 version.

Test Plan

All flavors tested in poudriere and on my workstation.

Diff Detail

Repository

rP FreeBSD ports repository

Lint

No Lint Coverage

Unit

No Test Coverage

Build Status

Buildable 31853
Build 29412: arc lint + arc unit

Event Timeline

madpilot created this revision.Jun 14 2020, 1:05 PM

Herald added a subscriber: mat. · View Herald TranscriptJun 14 2020, 1:05 PM

madpilot requested review of this revision.Jun 14 2020, 1:05 PM

Harbormaster completed remote builds in B31694: Diff 73104.Jun 14 2020, 1:05 PM

madpilot retitled this revision from Update sqliteodbc ports and merge slave as a flavor to Update sqliteodbc ports and merge slave port as a flavor.Jun 21 2020, 11:13 AM

Update review since a new version was released.

Harbormaster completed remote builds in B31853: Diff 73427.Jun 21 2020, 11:14 AM

Out of curiosity: Why do we actually still need sqlite2? The only leaf consumers of it seem to be the asterisk ports. Do they really need to depend on a library that has been abandoned in 2005? It seems that nothing uses sqliteodbc-sqlite2 and it could just be removed. Then there would be one less reason to keep sqlite2 around too.

databases/sqliteodbc/Makefile
31	FLAVOR is always defined above, so the `:U` is unnecessary.

In D25267#560031, @tobik wrote:

Out of curiosity: Why do we actually still need sqlite2? The only leaf consumers of it seem to be the asterisk ports. Do they really need to depend on a library that has been abandoned in 2005? It seems that nothing uses sqliteodbc-sqlite2 and it could just be removed. Then there would be one less reason to keep sqlite2 around too.

I admit I have not thought about this.

If there is interest in dropping sqlite2 from the ports tree I have no objection and I can simply drop support from it from the ports I maintain. I can even support such a proposition.

After some thought, since we are near the next quarterly branch, I think the best choice for me is to wait after the branch and remove ssqlite2 support from sqliteodbc and asterisk then, so the change will have time to settle before the next quarterly.

I'm closing this review request, since at that point no flavor will be added and no approval will be required.

Thanks!