Hello Pete, Am Dienstag, 1. Oktober 2019, 13:02:21 CEST schrieb Hans-Peter Jansen:

Am Dienstag, 1. Oktober 2019, 11:35:39 CEST schrieb Axel Braun:

...

Hello,

I'm currently working on packaging Orthanc. This installation can be extended with plugins, e.g. for database-backends and viewers.

Those plugins require the sources of Orthanc to compile (beside some other specialities).

Any other ideas how to solve this?

Check out: https://build.opensuse.org/package/view_file/X11:XOrg/xorg-x11-server/xorg-x 11-server.spec?expand=1

Specifically the -source package.

Thank you, a good example. This is using the -source additionally to the -sdk package (which is probably the -devel in that case). I dont see the benefit to be honest.... Cheers Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 10/1/19 7:05 PM, Axel Braun wrote:

Hello,

I'm currently working on packaging Orthanc. This installation can be extended with plugins, e.g. for database-backends and viewers.

Those plugins require the sources of Orthanc to compile (beside some other specialities).

In order to keep things easy and consistent, I packed the sources of orthanc into orthanc-devel. So with BuildRequires: orthanc-devel in the plugins one should be fine.

Now this is objected by the maintainer of the targeted development repository, sources inside -devel are not allowed.

Adding the othanc source tarball to each plugin separately sounds a bad idea to me. High risk of inconsistency. Having a -src package build together with -devel isnt smart either - it just adds overhead.

Any other ideas how to solve this?

Does it actually need all the sources to compile? Generally if its C or C++ the header files and libraries are enough (although sometimes plugins are different) traditionally the -devel package should just contain the header files installed into /usr/include/orthanc -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hey, On 01.10.19 11:35, Axel Braun wrote:

Any other ideas how to solve this?

Build Orthanc and plugins together in one spec, separate into different packages inside the spec? Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Morning all, Am Mittwoch, 2. Oktober 2019, 13:47:08 CEST schrieb Brüns, Stefan:

On Mittwoch, 2. Oktober 2019 02:11:39 CEST Simon Lees wrote:

...

On 10/1/19 7:05 PM, Axel Braun wrote:

...

Hello,

I'm currently working on packaging Orthanc. This installation can be extended with plugins, e.g. for database-backends and viewers.

Those plugins require the sources of Orthanc to compile (beside some other specialities).

In order to keep things easy and consistent, I packed the sources of orthanc into orthanc-devel. So with BuildRequires: orthanc-devel in the plugins one should be fine.

Now this is objected by the maintainer of the targeted development repository, sources inside -devel are not allowed.

Adding the othanc source tarball to each plugin separately sounds a bad idea to me. High risk of inconsistency. Having a -src package build together with -devel isnt smart either - it just adds overhead.

Any other ideas how to solve this?

Does it actually need all the sources to compile? Generally if its C or C++ the header files and libraries are enough (although sometimes plugins are different) traditionally the -devel package should just contain the header files installed into /usr/include/orthanc

The source packaging of the plugins is IMHO a mess.

May be, but it is what we are getting from upstream

The public headers which are installed by Orthancs "make install" target declare the plugin API (and, as its plain C, more or less the ABI). So in general, the two header files which are installed are sufficient to create (trivial) plugins.

The plugins use these headers, but also reuse some of orthancs code. This is done by setting the include pathes and by directly referencing the sources relative to the orthanc sources directory. (The plugins also provide copies of the plugin API headers, in 4 different versions, i.e. you can compile the plugins without the public headers, but not without private definitions. Go figure.)

I think the proposal by Henne Vogel (building the plugins within the main package) is the least evil here.

This discussion is moving away from the original topic (sources inside the - devel package or not) The proposal to build plugins together with the server sounds smart in the first hand, but is in fact a return to a monolithic application. It adds a huge complexity, as it combines different technologies and dependencies (database plugin vs. web viewer plugin) in a single build environment, instead reducing each package to just the required environment. Every plugin on top will increase complexity and effort to debug why a build fails.... (Feel free to branch and proof me wrong) Looking at http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSRCSOURCECODE there is no objection to have some source code placed under /usr/src. So the question to have sources packed for this unique use case or have it inside the -devel package is academic vs. pragmatic: Yes, it may be 'cleaner' to have it separate, but in fact it is only used to build plugins, so the source package will (for the known plugins) always be called together with - devel. It will most likely never hit the system of any end-user, unless you want to develop a new plugin. As consequence, from the pragmatic view there is no benefit to have sources separate. Cheers Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org