Am Mittwoch, 2. Oktober 2019, 13:47:08 CEST schrieb Brüns, Stefan:
On Mittwoch, 2. Oktober 2019 02:11:39 CEST Simon Lees
On 10/1/19 7:05 PM, Axel Braun wrote:
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
In order to keep things easy and consistent, I packed the sources of
orthanc into orthanc-devel. So with
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
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
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
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org