Created attachment 415870 [details] Tested subsurface-4.3 ebuild, this has slight modifications compared to 4.2 ebuild Please bump Subsurface to version 4.3.
Mind sharing the diff between 4.2 and 4.3? It's enough and immediately visible.
Created attachment 415916 [details, diff] diff between subsurface-4.2.ebuild and subsurface-4.3.ebuild
what's the reason to add a outdated version of subsurface to the tree? I think it would be better to invest some time to adapt the ebuild for version >=4.5.1 which, from a packages point of view, unfortunately bundles some libs...
(In reply to Martin Gysel (bearsh) from comment #3) > what's the reason to add a outdated version of subsurface to the tree? I > think it would be better to invest some time to adapt the ebuild for version > >=4.5.1 which, from a packages point of view, unfortunately bundles some > libs... Yes, Subsurface team has released several newer versions, but 4.5.0 require quite significant patch. I have tryed compile 4.5.0 version, but this version has several issues with QT5 native bluetooth – it won't compile with disabled BT. Unfortunately I have not yet tryed 4.5.1 version, but while browsing GIT repo I saw that at least one BT issue is fixed, but still I am not sure that 4.5.1 version compile correcly without patches. Also 4.5.x versions require QT5. Therefore in my opionon, if it is possible should wait 4.5.2 version.
The versions of subsurface in the tree depend on marble:4, which we are considering removing soon. It seems the newer versions upstream are ported to Qt 5, so it would be nice to get a version bump.
an updated 4.5.6 ebuild is available in my overlay at https://bitbucket.org/bearsh/bearshlay/src/HEAD/app-misc/subsurface/?at=master for testing I suggest to drop the -3.x and -9999 versions immediately, the -4.3 and 4.4 once 4.5.6 is in tree
please note starting with 4.5 some libs are bundled as required by upstream. if that's a problem, I suggest to completely remove subsurface from the tree, users can either install it from an (my) overlay or use the AppImage provided by upstream
Can't comment on libdivecomputer (though I see an ebuild would be in tree), but bundling marble is indeed a bummer.
Having discussed the matter and looked at the code, it seems to us (i.e. the g-p-m team) that given all the bundled libraries AND the fact the upstream clearly considers distribution-maintained packages as deprecated, the request for removal of Subsurface from Portage is a valid one. I will send last rites for it soon.
(In reply to Marek Szuba from comment #9) > Having discussed the matter and looked at the code, it seems to us (i.e. the > g-p-m team) that given all the bundled libraries AND the fact the upstream > clearly considers distribution-maintained packages as deprecated, the > request for removal of Subsurface from Portage is a valid one. I will send > last rites for it soon. that's probably the best solution right now. thanks
Created attachment 445294 [details] subsurface-4.5.6.ebuild For completeness, here is a sort-of working ebuild for Subsurface-4.5.6. There are, however, many caveats: - using CMAKE_MAKEFILE_GENERATOR=ninja immediately fails compilation, one must use emake; - in order for the ebuild to compile at all it is necessary to comment out or delete line 1034 from libdivecomputer.c because the device it references is only supported by dev-libs/libdivecomputer-9999; - USE="print" does not work because for some reason CMake fails to locate dev-libs/grantlee. This could probably be fixed on our end; - USE="doc" is mandatory because even with NO_DOCS=yes passed to CMake, it still tries to install the files and fails due to user-manual.html not having been generated. Again, this could probably be fixed on our end; - USE="serial" does not work because it requires a version of libdivecomputer customised by Subsurface developers. No way around this; - USE="marble" does not work because it requires a version of marble customised by Subsurface developers. Again, no way around this.
I really don't see a reason to try to unbundle subsurface as they have modified marble and libdivecomputer quite heavily. especially libdivecomputer, at least in the past, was not able and/or willing to include some features needed by subsurface. therefor and given the fact that there are no other libdivecomputer consumers in the tree, it makes sense to use the bundled version. if you look at the ebuild in my overlay [1], marble and libdivecomputer are used from subsurface upstream. unfortunately it doesn't compile anymore for me. it seems it picks up the system version of marble which doesn't work, although it shouldn't... [1] https://bitbucket.org/bearsh/bearshlay/src/02472f188347ea974fe2a4890cb8cc00397cf718/app-misc/subsurface/subsurface-4.5.6.ebuild?at=master&fileviewer=file-view-default
There seems to be many instances where 'pre-packaged' creates a situation where unbundling is not warranted due primarily to the additional amount of work; I (most of us) get that. What would be nice for users of gentoo would be for the gentoo developer community to formalize a reasonable secure semantic for installing these sorts of codes, formally or routinely, as either a VM or secured container, on an otherwise gentoo workstation, so folks could continue to enjoy these packages. Once that is discuss, then perhaps some tests and a wiki page, not with all the possible methods to achieve, but merely a documented example that could form the basis for users to follow. The idea would be for many packages that get purged from the gentoo tree (for a variety of reason like embedded libs) to have a formal installation semantic, well defined and available as an option for the general user community. A caveat of 'you are on your own if you do this', would be fine and limit gentoo responsibility. James
app-misc/subsurface has been removed from the tree. Please use Martin's overlay if you want to keep it under Portage control, or use AppImages provided by upstream.
