TOPIC:

Hello,

nice to see a team restarting to work on a grib display. Having multiple Grib sources is great.

Now my packaging exercise is not going nicely, I had to do a lot of hacking. Nothing serious but quite a few niggle that will need correction, in order to move xygrib as an official package.

1) Debug symbols

---

Most Distros do not allow to keep the debug symbols in standard package.
Debug symbol are created by running cmake with the debug option.
I had to strip debugs and deactivate the debug build to pass.

2) Directory

---

Your executable cannot be installed by make in a directory which is in the executable path, if you are to respect the Linux standards.
It's actually already indicated in your documentation. Needs fixing. Good news, it's simple.
It's easy to correct as we can either use multiple variables in cmake or; as in OpenCPN, use a single prefixvariable and then use /usr/bin and /user/share/xygrib
Currently I need to move the file in the build root before packaging. Pretty ugly.

Man page

---

a small man page would be nice.
It would avoid an error during packaging check and it would be a great opportunity to add debug and version check options.
--help -h
--version -v
--debug -d

Today, when you have an error, it"s not obvious to know why.
A debug flag would help.

3) .desktop file

---

You have only done one for Debian, why ?
Why is it not installed ?
It would work.
Today I need a hack in the packaging to get it in the right place.
an icon in svg would be nice as it would allow to support multiple size.
Today we have a ratio screen size to definition which is very variable.

4) New version download

---

On a boat you do NOT want code with connects on the internet for you.
Update is done when in a harbour, because data at sea are not cheap and update can break your system and you really need it.
e.g. for that reason, I only build for the running OpenSUSE release in my test sandbox but I only publish for stable releases in the official repo.

Furthermore, code is install in a location where you need to be root (admin for Win users), to write anything, so update should fail anyhow.
So my question, is which cmake option, can I use for building without the auto-update feature.

This is for me a show stopper and I will not push it to the main repo, until I have a way to deactivate the feature.

5) Capitalisation

---

On Linux it"s a PAIN.
It fails search, auto-completion, ...
Could we get only lower case in file names.

6) Reuse my packaging.

---

You are well come to reuse my packaging a a base for your own tests.
I hope to clean it up once that the previously listed issues are corrected.

My config download master from github at each service run.
You could even trigger a service run each time you do a github commit.
I do not, as I am focussing for secure use at sea.
see openbuildservice.org/2013/11/22/source-update-via_token/

You can also build for other Linux distros but this is not my focus.


Regards

Dominig

Hello,
Thank you for your comments.
Involved persons like you are highly welcome. This really allow to improve the quality and the functionalities of XyGrib.
As you know, the app is a fork of zyGrib and is not starting from scratch. A lot of cleaning has already been done, a lot still to be done; there is the need to take into account that there is an long history with quite a large number of users, that appreciate that the app is still working in the own environment; which means in this transition phase you will find elements of the future config and still some from the past.
Anyway, I suggest you to join the team on github (github.com/opengribs/XyGrib).
Thanks a lot

Hi,

In all honesty I feel the need to express my position on Linux distro packaging. I'm against it!
I'll expand a bit on what I feel is bad about it and then address the alternative route.

On a small project (small in the number of contributors), packaging leads to spending 80% of the total effort on preparing releases and leaves only 20% effort for product development. This should be the other way around with most of the man hours spent on improving the product and not on packaging it for every esoteric Linux distro.

Having a small team will then result on others picking up the packaging challenge, which of course they are free to do, but later when users start to have problems they come to us for solutions and I don't think that it is good policy to say "Go and take your problems to whoever prepared your package".

More than than that. We are putting out quite frequent updates to the software and there is no way that official packages can keep up with this. Again it results in problematic user support i.e. "Where did your installation come from?.... Why don't they have the current version?... Oh I can't help you on that!"

We are proposing an alternate route which is in line with the evolution that is occurring.
Our installer system for Linux is good for all distros as it installs an AppImage application (think container with all prerequisites). This is somewhat similar to OSX's solution of distributing applications. It leads to one installer for all Linux distros from one source only.

The good news is that it works and it works smoothly. In the last two releases we have hardly had any Linux user issues with installing and running - only good responses. All we need to do on every software update is prepare one Linux set of application files which goes to our own repository and the installed software instances can update themselves using the XyGrib Maintenance Tool.

I know that the proponents of disto packaging or even better, "build it yourself", will argue the downsides of App Images from here to Kingdom come but realistically what is wrong with a bit of excess baggage when you can easily afford it?

David

Packaging presents a small hurdle to start but them gives many advantages (took me a few hours) but:
- search by name in the Distro package DB and 1 click install
- no need to install side packages that can easily leads to full distro instability if a mistake is done
- automatic install by dependency (in my case with OpenCPN)
- automatic maintenance when support packages are upgraded (eg. QT)

It's not in Windows culture at all because the culture of close code has forged the process.
But in Linux world it's an easy way to get a free "continuous integration" multi user shareable solution.

For the quick update, you can automate the creation of new package directly when you hit git push, then the users are update even if they have not use the package. Assume 10mn for all process. Embedded update is not quicker but rather equivalent but with a big added value, on mist distro, you can roll back if needed.

Your solution makes sense for WIndows, even if in the future, most likely, install by the App Store will be the only usable option for non developer.
For OpenSUSE,, I will stick to package install f if I fail to do with your code, I will find something else, but I see no reason to fail.

It's obvious that your initial focus is on Windows, most of my issues are generic to Linux.

Dominig

I'm totally focused on Linux users and have (after some time) realized that the very large majority of Linux users are not developers and do not care at all about continuous integration or building etc.. All they want is the ease of use and installation that Windows and Mac OSX provide.

The problem is that the very verbal minority of Linux users keep dictating that the entire user community be geared to what is comfortable for experienced developers.

One cannot ignore the user community. In the case of XyGrib 70% of users are using it in Windows. The remaining 30% is roughly divided between Linux and Mac OSX (say 20% to 10%). Of the 20% of Linux users 9 out of 10 prefer the simplicity of the QT installer system (using AppIMage) to provide them with a usable setup that is universal for all distros.

The remaining 2% or less are indeed experienced Linux developers who don't even need a distro package - they know how to git the sources and build and create their own installation each according to his/her own preferences. There is absolutely no need to invest energies in this group of users.

Hello,
stormy days are great for coding.
I have fixed my 2 major issues and I will now create the OpenSUSE package in my sandbox from my temp fork.
I have 2 merge requests pending. Standard code behaviour has not been changed.
I will push it in official OpenSUSE repos after more tests in a week or 2.

Dominig