Re: [cocci] Flatpak package for Coccinelle

[Jan Tojnar <jtojnar@gmail.com>]

On Tue, 2024-06-25 at 17:46 +1000, Julia Lawall wrote:
> I believe that I wrote the text.  Unfortunately, it predates the
> websute
> git repository.  Do you have any suggestion about the licenses?

Any of the licenses acceptable for the AppStream metadata is fine:

https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-metadata_license

Personally, I am fond of Creative Commons Attribution-ShareAlike for
websites.

Just like GNU GPL, it requires derived works to use the same license,
preventing the re-licensing to non-open-source license without the
consent of all contributors/copyright holders (though this is currently
trivial, if you are the sole author of the website).

https://creativecommons.org/licenses/by-sa/4.0/deed.en

CC licenses also have more approachable websites and I find the terms
more readable than GNU licenses – compare GNU Free Documentaion License
with the CC-BY-SA text:

https://www.gnu.org/licenses/fdl-1.3.html
https://creativecommons.org/licenses/by-sa/4.0/legalcode.en

Also it might depend on the agreement you have with your employer. I am
not a lawyer but I believe that typically, the company/university owns
the copyright (well economic rights, at least) to works you produced
“on their time” so they might need to agree to any relicensing.

It might be easier to write a new description if you are not sure about
the legal status.

> I would hesitate at the moment to touch the version release script if
> it
> is not necessary.  Currently, we have no maintainer for this code.
> Someone new will start working on Coccinelle in the fall, and perhaps
> this
> person could help with this.  But for now it seems safest not to
> complicate the release process.

If the script were not modified and we included the metainfo file in
the repository, we would need to update the file manually before each
release.

The procedure consists of updating the version and release date in the
metainfo file (the following line):

    <release version="1.2" date="2024-03-28" type="stable"/>

I would say it is easy to forget and pretty amenable to automation.

> 
> What is the maintenance effort involved here?  Because it is often
> the
> case that if someone reports a bug, then we fix it and hope that the
> person will be able to use the source code from github.

It is pretty much like maintaining a package for any other package
management system/Linux distribution.

- It can break when you break something in the code. This will likely
be also a problem on other platforms so you should fix it.
- It can break when you use a dependency that is not available in the
environment (e.g. require too new version of OCaml) or forget to bundle
a dependency (for simplicity, I made the manifest use bundled
dependencies instead of downloading them from opam). This can be a
problem if you e.g. wanted to use latest OCaml version. It would
require adjusting the manifest.
- It can break when you change the build system API. Currently, the
Flatpak manifest expects standard Autotools build and would need to be
adjusted if it changes.
- The Flatpak SDK or the OCaml extension can break. Hopefully, this
would be rare. In that case, the cause would need to be investigated
and reported.
- Once a year, one should bump Flatpak SDK version to get newer
versions of packages.

I can do the Flatpak-related maintenance for the foreseeable future but
I cannot guarantee timeliness. So I can imagine a situation when you
make a fix, start to rely on sending people Flatpak links to test
changes, only to find out that it is suddenly broken, and I am on
holidays in the Australian outback for a month.


> Sorry, I don't understand the relation between 4 and 5.  Is there one
> thing to do with two benefits?

(4) is prerequisite for (5).

(4) is already implemented in
https://github.com/coccinelle/coccinelle/pull/370

(4) requires Flatpak, flatpak-builder, cloning the Coccinelle
repository and then running a command to have flatpak-builder build
Coccinelle from the manifest.

(5) would just require Flatpak, the other steps would be done by
GitHub/GitLab CI, so user would run command like the following to
install a pre-built package:
https://github.com/flathub/flathub/pull/5354#issuecomment-2184988422

(5) would require introduction of GitHub/GitLab CI configuration file
into the repository and perhaps some configuration changes to
GitHub/GitLab repository (regarding storage of built assets).


Cheers,
Jan