Provide a way to disable thick-mode during build/install

[jnahmias]

1. Describe your new request in detail

Thank you for your efforts to provide an Oracle driver for Python that does not need the Oracle client libraries in order to connect to the database!

As you may be aware, software in the main section of the Debian archive must comply with the Debian Free Software Guidelines both itself and any build/run dependencies; thus, we have had odpic & cx_Oracle in the contrib archive section due to the runtime need for the proprietary Oracle client libraries.

With the release of python-oracledb and the availability of the thin-mode driver, I have taken the opportunity to package it for the main section of the archive, as the Oracle client libs are no longer necessary. However, in order to do so successfully, I needed to disable the thick-mode driver -- which I did in a bit of a rough way (patch).

It would be great if there were a supported way to configure/build/deploy only the thin-mode driver and have python-oracledb fail gracefully with a polite error message if the thick-mode driver is requested.

2. Give supporting information about tools and operating systems. Give relevant product version numbers

Debian GNU/Linux testing/unstable
Python 3.11.1
Oracle Database 19.13.0.0.0
python-oracledb 1.2.1

[anthony-tuininga]

Thanks for the suggestion. I'll take a look into this!

[cjbj]

@jnahmias Thanks for working on the bundle. What's the real benefit from being in main? My concern with removing the Thick mode is that some users may want it because it has additional functionality. I know users could ignore your package and install with pip, but this seems less useful than having python-oracledb (both modes) in contrib. How do you see it? Or do you have some other plan for making Thick mode available?

[anthony-tuininga]

Just for clarity: thick mode doesn't require any build dependencies. At runtime, a call to init_oracle_client() is required in order to enable thick mode. It is at this point that the proprietary Oracle Client libraries are searche for and loaded (if found). So, if you simply remove (or disable) the call to init_oracle_client(), thick mode can't be used.

It would be helpful to get the answers to Chris' questions in order to know what is desired. Thanks!

[cjbj]

@jnahmias is there any update on this?

[jnahmias]

Hi all, thanks for the ping. Must have missed the original replies -- life has been busy...

@cjbj Only the main archive section is considered Debian proper and that is the only section (ignoring the recent addition of nonfree-firmware) enabled by default on a fresh install.
Enabling contrib is not terribly difficult to do (a quick web search turns up instructions) and I believe there might even be an opt-in question in the installer (but haven't checked recently). The drawback is that the user needs to know what contrib is and that they need to enable it to get access to the python-oracledb package (in which case, it's 50/50 if they figure this all out or say screw it and just pip install instead).
My gut feeling is that the thin-client is likely sufficient for 80%+ of users and so I would like to have it available by default for the majority; however, that's just my opinion -- do you have any good data on this (thick vs. thin needs/usage)?

@anthony-tuininga The general rule in Debian is that we unbundle embedded/vendored libraries and have them as separate packages with appropriate binary package dependencies and dynamic linking such that everything JustWorks™. So when packaging python-oracledb, the embedded copy of odipc is stripped out and packaged separately and must go to contrib due to its dependence on the Oracle Client libraries. If I take your suggested approach, I would still be building the thick-mode part of the driver and thus need the build-dep on odpic -- dragging python-oracledb into contrib (the same way cx_Oracle was/is).

I hope this helps give some context and explain the situation more fully. Again, I'm so pleased that you've created the thin-mode driver and made it available so I could package it in Debian for myself and others to use easily. FYI - It is slated (in its current state) to become part of the next version of Debian which will hopefully be released in Summer 2023. Debian also feeds downstream into other Linux distros and Ubuntu 23.04 [Lunar], which should release in April 2023, has already picked it up from Debian.

[cjbj]

@jnahmias Since Debian probably won't make Instant Client a package, install for users who want Thick mode won't "just work" via apt etc so I don't see a lot to be gained by moving the ODPI-C code to contrib. Users will need to manually install Instant Client. Plus this kind of code surgery will be invasive and a maintenance chore.

With our full code base, any user trying to use Thick mode features but not having Instant Client will get a clean error message that the functionality isn't available. In my eyes, the full code base including ODPI-C can be viewed as part of python-oracledb whereas Instant Client could be seen as vendored libraries. So I would still argue that you should build our full code base and release it in main.

However if you think it will be seen differently and

• (i) want to ship in main (which sounds ideal), and
• (ii) don't want Thick functionality to be available in any way to users even if Instant Client is installed separately by them

then I would be OK with you disabling Thick mode altogether. Users can install via pip if they want a driver that works with Thick mode. In this case I suggest you follow Anthony's solution regarding removing (or disabling) the call to init_oracle_client() since this minimal change will make ongoing package maintenance simpler for you.

To repeat, let's get this in main, with or without the capability to switch to Thick mode.

[jnahmias]

@cjbj Okay, perhaps it wasn't clear from above, but python-oracledb is already in main for unstable and bookworm (testing). FYI, testing is the staging ground for the preparation of the next stable release (codename: bookworm); it is currently in "soft-freeze" where new packages will not be accepted, but updates containing small/targeted fixes will (more details at https://release.debian.org/testing/freeze_policy.html).
You can track the status of the package in general (and subscribe to updates, if you wish) at its Debian package tracker page https://tracker.debian.org/pkg/python-oracledb.
Similarly, odpic and cx_Oracle are both already in contrib. Tracker pages: https://tracker.debian.org/pkg/odpic and https://tracker.debian.org/pkg/python-cx-oracle.

I'm going to disagree with you that ODPI-C should be considered as a bundle with python-oracledb. My understanding is that it's designed as a proper shared library that is used by multiple language-specific Oracle database drivers. In which case, when we package those drivers in Debian, we'd want them all to dynamically link to the same libodpic4 -- not each have their own embedded copy.

Having said all that, I'd be happy with a solution that allowed users to cleanly use the thick-mode driver after downloading the instant client. I'd also be happy to package the instant client, but we'd need the source and a license that, at least, allowed redistribution (for non-free).

In any case, I need to do some checking on my end to see whether/how we are allowed to build binary packages targetting main & contrib from the same source package.

[cjbj]

Thanks for the links (and the work!)

My understanding is that [ODPI-C is] designed as a proper shared library

It is designed as a multi purpose library. But we don't use it as a shared library with drivers. Each language driver can (and does) pick up ODPI-C from a stable SHA - these can differ between drivers. This is the code base for that driver that is tested, tagged and released. We don't/haven't configured the drivers to be able to use a separate ODPI-C shared library.

Instant Client's license does allow redistribution but you should get Debian's lawyers to review the paperwork!