added: debian packaging control files

[akva2]

This adds the debian packaging fluff for ResInsight.

Note that the generated packages will be corrupt as long as the butchered install path is used (set in CMakeLists.txt in main git - what the insert nasty word)

[akva2]

this is now on top of my packaging list.

i need to change the approach for libert.ecl. shall i keep the option to use an in-tree copy on linux or remove it?

i also need to fix the install path mentioned in the pr description. do it through an option and keep the current intact or make it behave like expected once and for all?

[magnesj]

We are aware of these issues, but we have no plans for cleaning up the installation / packaging system in the near future.

[akva2]

@alfbr @atgeirr ^^^

[alfbr]

We do have up-to-date installations of out-of-tree Qt on all linux-systems that run Resinsight, so I assume it would be good to hear why linking the ordinary way is impractical. That said, @akva2 it is very helpful if you are a bit more verbal. I often find it difficult to interpret you posts ;)

[akva2]

okay, the more verbose version;

i cannot do as requested from me (do in-tree packaging for all opm modules) since upstream won't accept it. since i'm not the type who let such things stop me from doing my job, i will make the packaging available in a separate repository, which i will sync with opm releases only.

[rolk]

@akva2
I think what @alfbr meant was: Where is the offending code in CMakeLists.txt? (I have no doubt that there is, just to save us from having to parse the entire thing). Other than that I agree that you should just make the necessary changes in a 'debian' branch, which upstream can merge when it comes to its senses.

[akva2]

it's not contained in a few lines...

1. ert is hosted in tree. there is no find rule in use, but hardcoded library names, paths and rpaths. it also uses non-standard include paths (after the ert changes) - i.e. ecl_foo.h instead of ert/ecl/ecl_foo.h which is the intended after the ERT refactor.
2. no find rule used for octave.
3. files are installed to a single directory on make install, not following linux standards (no /usr/bin/ResInsight, no /usr/share/doc/resinsight aso).
4. it installs copies of all qt libraries along the main binary, ignoring the fact that these link to tons of other system libraries so they would be completely useless on their own.
5. it installs the octave files in the very same flat directory, forcing users to manually do an addpath every time they start octave (or they have to put it in their .octaverc).

as you can see it requires quite some changes which is why i asked for upstreams opinion on those very simple to answer questions, implying i'd do the work.which i have now done, but not in a mergeable way.
i have to skip all alignments etc in the added code (and dupe lots to avoid +- blocks) as it will be easier to maintain these patches that way. you can see the start of my hackery at https://github.com/akva2/resinsight-packaging

it only holds the debian packaging right now, but it successfully produces proper packages. i'll push the centos asap and notify the mailing list.

[akva2]

and i don't want to make it a full fork of the project. i don't want to give the impression i'm maintaining anything but the packaging and build system changes.

[rolk]

@akva2
I still would have made it a branch; makes it a lot easier to merge later (cf. how cmake builds are implemented in opm-core)

[akva2]

i'm making this the most convenient for me, not the most convenient for upstream. i'm already hopping through hoops for reasons unknown to me.

obviously i have a local git i use to generate the patches for the debian setup.

[rolk]

4}. it installs copies of all qt libraries along the main binary, ignoring the fact that these link to tons of other

It is actually worse than that; the ResInsight binary has indeed an rpath engraved, but it is the wrong one (seems to be using ${CMAKE_INSTALL_PREFIX} instead of ${CMAKE_BINARY_DIR}/Install, where the files are), so none of the Qt libraries will be loaded, as is.

At least the wrapper could pull its weight and say

exec env LD_LIBRARY_PATH=$INSTALL_PATH:$LD_LIBRARY_PATH ./ResInsight "$@"

[alfbr]

Great, that will give us a quick fix. I hope we can get a more unified solution over time. At least for Qt and Ert this should be easy, for octave I am less sure. Install location is also tricky, since we do out-of-tree installation on this, typically we do not have root privileges, which I guess basically is incompatible with debs and rpms, so this one will need a switch, and I guess Roland's suggestion with cmake is the best approach.

[alfbr]

Just realised I posted in the wrong thread, this discussions seems to take place everywhere :) In any case, the quick fix I talked about is the separate set-up you did for the packaging, basically supporting both the current way and proper packaging. It is not ideal, so I suggest we do a discussion on what how we can bring the packaging closer to the upstream install. I cannot see that we are in a hurry on this, as I will be out of circulation for two weeks.