We recently submitted a new mingw package for osgearth.
This package made use of split packages (i.e. to produce two packages : osgearth and osgearth-debug) in a way similar to the existing OpenSceneGraph package.
We were told not to use split packages as it generates more work for the maintainers. Fair enough...
So now the questions is what are the alternatives to using split packages to produce release and debug packages for a given framework ?
One solution would be a single package that contains both release and debug binaries (the qt5 package does that).
Another solution would be two completly separate packages.
What's the recommended / accepted solution ?
Regards,
Philippe.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We recently submitted a new mingw package for osgearth.
This package made use of split packages (i.e. to produce two packages :
osgearth and osgearth-debug) in a way similar to the existing OpenSceneGraph
package.
We were told not to use split packages as it generates more work for the
maintainers. Fair enough...
So now the questions is what are the alternatives to using split packages to
produce release and debug packages for a given framework ?
One solution would be a single package that contains both release and debug
binaries (the qt5 package does that).
Another solution would be two completly separate packages.
What's the recommended / accepted solution ?
Hi Philippe,
It is a tricky one ..
How much build-time and size does the debug variant libraries add to
the package? Packages cannot have any file overlap either, so you'd
have to spit it carefully and make the debug depend on the non-debug,
but that's all achievable for sure.
For me, there are plenty of packages that I would quite like to have
debug variants built as binaries, but the workload would be too much,
so I don't ask. Our Python packages are a good example of this.
Instead, I make it very easy to edit the PKGBUILDs to build the debug
variants then build them locally. Generally speaking, I make sure that
setting the options=('debug' '!strip') "do the right thing", but you
can do it however you feel is best.
You could go back to how you had it the PKGBUILD written to be
split-packages capable, but then push it to us with the pkgname array
containing only a single entry, for the release builds, then when
someone needs the debug version, advise them to build it themselves.
pkgname=("${MINGW_PACKAGE_PREFIX}-${_realname}")
The thing is, debug packages with source code paths pointing to files
that aren't on the local machine and pathed correctly and that aren't
quickly editable and re-'make'-able are only of limited use anyway.
The strategy I employ for PKGBUILDs and development / debug versions
is to try to commit mingw-w64-${pkgname}-git/PKGBUILD packages which
(as you'd expect!) pull down the sources from the source repository
and build the very latest master version, in debug mode, using "git
am" to apply any local patches. I try to do my MSYS2 specific
development work in there and then copy the patches into the non-git
version of the package. We tend not to build binaries for the -git
versions (only in exceptional situations), so we'd welcome a pull
request for mingw-w64-osgearth-git/PKGBUILD setup in this way.
Seems like there is no fit-all solution and the best approach depends on the nature of the package.
Concerning osgearth :
Osgearth is an extension of OpenSceneGraph and cannot be built or used without OpenSceneGraph. As such osgearth and OpenSceneGraph share a lot (very similar build procedure, dependencies, ...).
So it would make sense that their respective PKGBUILD are also made similar.
OpenSceneGraph uses split packages for release and debug builds, and respects the critiria given above for such an approach (i.e. no file overlap, debug package dependent on release one, ...).
Build time of osgearth is roughly doubled and the osgearth-debug package size is of the same order of magnitude as the release package.
osgearth-debug would be dependent on osgearth and OpenSceneGraph-debug.
So the proposed approach is to :
Make the new osgearth package similar to the existing OpenSceneGraph package.
The two packages could then later co evolve if a another approach is preferred.
Best regards,
Philippe.
Last edit: Philippe Renon 2016-02-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Seems like there is not one fit-all solution and the best approach depends
on the nature of the package.
Concerning osgearth :
Osgearth is an extension of OpenSceneGraph and cannot be built or used
without OpenSceneGraph. As such osgearth and OpenSceneGraph share a lot
(very similar build procedure, dependencies, ...).
So it would make sense that their respective PKGBUILD are also made similar.
OpenSceneGraph uses split packages for release and debug builds, and
respects the critiria given above for such an approach (i.e. no file
overlap, debug package dependent on release one, ...).
Build time of osgearth is roughly doubled and the osgearth-debug package
size is of the same order of magnitude as the release package.
osgearth-debug would be dependent on osgearth and OpenSceneGraph-debug.
So the proposed approach is to :
Make the new osgearth package similar to the existing OpenSceneGraph
package.
The two packages could then later co evolve if a another approach is
preferred.
Well, there's a strong chance I was wrong, it certainly sounds that
way. If we've gone for OSG-debug then osgearth-debug sounds necessary.
The core problem is the we need automation and infrastructure for the
packaging side of things. And more people.
Hi,
We recently submitted a new mingw package for osgearth.
This package made use of split packages (i.e. to produce two packages : osgearth and osgearth-debug) in a way similar to the existing OpenSceneGraph package.
We were told not to use split packages as it generates more work for the maintainers. Fair enough...
So now the questions is what are the alternatives to using split packages to produce release and debug packages for a given framework ?
One solution would be a single package that contains both release and debug binaries (the qt5 package does that).
Another solution would be two completly separate packages.
What's the recommended / accepted solution ?
Regards,
Philippe.
On Mon, Feb 1, 2016 at 5:27 PM, Philippe Renon filnet@users.sf.net wrote:
Hi Philippe,
It is a tricky one ..
How much build-time and size does the debug variant libraries add to
the package? Packages cannot have any file overlap either, so you'd
have to spit it carefully and make the debug depend on the non-debug,
but that's all achievable for sure.
For me, there are plenty of packages that I would quite like to have
debug variants built as binaries, but the workload would be too much,
so I don't ask. Our Python packages are a good example of this.
Instead, I make it very easy to edit the PKGBUILDs to build the debug
variants then build them locally. Generally speaking, I make sure that
setting the options=('debug' '!strip') "do the right thing", but you
can do it however you feel is best.
You could go back to how you had it the PKGBUILD written to be
split-packages capable, but then push it to us with the pkgname array
containing only a single entry, for the release builds, then when
someone needs the debug version, advise them to build it themselves.
pkgname=("${MINGW_PACKAGE_PREFIX}-${_realname}")
The thing is, debug packages with source code paths pointing to files
that aren't on the local machine and pathed correctly and that aren't
quickly editable and re-'make'-able are only of limited use anyway.
The strategy I employ for PKGBUILDs and development / debug versions
is to try to commit mingw-w64-${pkgname}-git/PKGBUILD packages which
(as you'd expect!) pull down the sources from the source repository
and build the very latest master version, in debug mode, using "git
am" to apply any local patches. I try to do my MSYS2 specific
development work in there and then copy the patches into the non-git
version of the package. We tend not to build binaries for the -git
versions (only in exceptional situations), so we'd welcome a pull
request for mingw-w64-osgearth-git/PKGBUILD setup in this way.
Best regards,
Ray.
Hi Ray,
Thanks for the detailled answer.
Seems like there is no fit-all solution and the best approach depends on the nature of the package.
Concerning osgearth :
Osgearth is an extension of OpenSceneGraph and cannot be built or used without OpenSceneGraph. As such osgearth and OpenSceneGraph share a lot (very similar build procedure, dependencies, ...).
So it would make sense that their respective PKGBUILD are also made similar.
OpenSceneGraph uses split packages for release and debug builds, and respects the critiria given above for such an approach (i.e. no file overlap, debug package dependent on release one, ...).
Build time of osgearth is roughly doubled and the osgearth-debug package size is of the same order of magnitude as the release package.
osgearth-debug would be dependent on osgearth and OpenSceneGraph-debug.
So the proposed approach is to :
Make the new osgearth package similar to the existing OpenSceneGraph package.
The two packages could then later co evolve if a another approach is preferred.
Best regards,
Philippe.
Last edit: Philippe Renon 2016-02-02
On Tue, Feb 2, 2016 at 10:41 AM, Philippe Renon filnet@users.sf.net wrote:
Well, there's a strong chance I was wrong, it certainly sounds that
way. If we've gone for OSG-debug then osgearth-debug sounds necessary.
The core problem is the we need automation and infrastructure for the
packaging side of things. And more people.