Package for debian

[almet]

I think it could be nice to be packaged for debian. However, I'm completely out of the hype on this, and don't know where to start. I would be very happy to have some guidance from you @JocelynDelalande as it seems you know a bit how it works.

What do you think? What would be the steps in order to have something in the debian repositories?

[Phyks]

I recently came across Yunohost which is a solution built on top of Debian to selfhost easily and painlessly.

I don't think there is an app achieving the same goal as ihatemoney packaged for it yet, so maybe it would be worth writing a ihatemoney package. There is an app for Kresus for instance, and it should be quite easy to write an app. Basically, it's just a couple of bash scripts to write to handle the installation in an automated way. Anyone able to install ihatemoney on its own should be able to write the installation scripts.

Not sure how valuable this advice is, but I know Yunohost community is quite large and getting momentum, so it could bring new users and contributors :) Packaging for Debian would ensure Yunohost compatibility directly, but packaging for Yunohost might be a first step easier to achieve? Anyways, that's just my two cents on this :p

[almet]

Thanks for the proposal. Actually, Ihatemoney is already packaged for yunohost, thanks to the work of @JocelynDelalande. We might want to advertise it in our documentation ! The package is at https://github.com/YunoHost-Apps/ihatemoney_ynh

[Phyks]

Oh, I missed it, that's awesome!

[almet]

As of today, here is the list of missing python packages in debian, in order to package IHM there.

Required version (from requirements.txt)	Packaged version (in debian stable)
alembic==1.1.0	python3-alembic (1.0.0-3)
aniso8601==7.0.0	python3-aniso8601 (4.1.0-1)
Babel==2.7.0	python3-babel (2.6.0+dfsg.1-1)
blinker==1.4	python3-blinker (1.4+dfsg1-0.2)
Click==7.0	python3-click (7.0-1)
dnspython==1.16.0	python3-dnspython (1.16.0-1)
email-validator==1.0.4	MISSING
Flask==1.1.1	python3-flask (1.0.2-3)
Flask-Babel==0.12.2	python3-flask-babel (0.11.2-2)
Flask-Cors==3.0.8	python3-flask-cors (3.0.7-1)
Flask-Mail==0.9.1	python3-flask-mail (0.9.1+dfsg1-1)
Flask-Migrate==2.5.2	python3-flask-migrate (2.1.1-2)
Flask-RESTful==0.3.7	python3-flask-restful (0.3.7-1)
Flask-Script==2.0.6	python3-flask-script (2.0.6-1)
Flask-SQLAlchemy==2.4.0	python3-flask-sqlalchemy (2.1-3)
Flask-WTF==0.14.2	python3-flaskext.wtf (0.14.2-3)
idna==2.8	python3-idna (2.6-1)
itsdangerous==1.1.0	python3-itsdangerous (0.24+dfsg1-2)
Jinja2==2.10.1	python3-jinja2 (2.10-2)
Mako==1.1.0	python3-mako (1.0.7+ds1-1)
MarkupSafe==1.1.1	python3-markupsafe (1.1.0-1)
python-dateutil==2.8.0	python3-dateutil (2.7.3-3)
pytz==2019.2	python3-tz (2019.1-1)
six==1.12.0	python3-six (1.12.0-1)
SQLAlchemy==1.3.8	python3-sqlalchemy (1.2.18+ds1-2)
Werkzeug==0.15.6	python3-werkzeug (0.14.1+dfsg1-4)
WTForms==2.2.1	python3-wtforms (2.2.1-1)

We would have to check that the current IHM version is compatible with the debian-packaged version of the library, but I can't see why it would break.

it means we are missing only one library in debian in order to package IHM there : email-validator used to check the emails in the invite form.

So, either we package it for debian ourselves (I still don't know how :p), or we try to do the check another way!

In any case, it's good news : that's the only missing lib.

[Glandos]

It seems that there is no packaged alternative. And doing email validation manually is risky, at best. Maybe the solution is to rely on the SMTP, since we will eventually send an email. And the invite form can also use HTML5 email validation. It's not server side, but since data is only used to send an email, it should be enough.

[almet]

I'm not sure it's easy to validate multiple, comma separated emails on the web side, but it's probably doable!

[aeris]

Just don't validate email :smile: There is too much corner cases and almost anything is a valid email address in practice.

[almet]

For the proof of concept debian package, we can surely do that. After, I think the best way to do it would be to either vendorize the content of the package somewhere in IHM, or package it for debian (it shouldn't be too hard ?)

[aeris]

Packaging is not the main problem. The problem is packaging means become officially the Debian maintainer :yum: Debian policy rejects vendoring or others tricks. All dependencies must be packaged and officially integrated to Debian for a package.

[almet]

Why not! For a small library such as this one I think I could maintain.

[almet]

@aeris did you manage to get a hand on your scripts?

[aeris]

Yep, I'm currently on it for Cozy. Will release it soon, and write a blogpost to explain Debian packaging.

[almet]

Hey @aeris, any news on this front?

[aeris]

Currently very busy at work (on Debian packaging :joy:) :tired_face: Build environment begin to be published here but lacks of doc at the moment.

[aeris]

This env is only used for building & publishing. The packaging part need to be address specifically for each package. For python, doc is mainly here.

Main problem is the interactive installation, with question asked to user for setup, and integration with nginx, vhost, tls & cie. Debian packaging is just a nightmare on this part, with old-school low-level bash scripting and no standard & easy way to achieve this…

[Glandos]

At least you can ask questions while installing. In RPM, it is just not possible to do that.

[almet]

… The problem I have with OS-packaging still stands : I can't understand where to start. In the links you provided, they reference concepts I know nothing about and that makes me impossible for me to get started.

But, this message is not to complain : I would love to find a solution to this problem, but I believe I don't want to read all the documentation because it's too dense and not grouped in one place.

So if anyone got any idea on how we should do this, that would be great. It's also possible to find a time to do this in pair-programming maybe?

[aeris]

A good starting point is this presentation, available in french here.

Packaging is quite difficult to learn, doc is sparse, no single reference, multiple tools alternatives… :sob: Take a look at the howto above, then look for already packaged software closed to what you want to package, then… pray and start yours :joy:

[almet]

Thanks! Do you have any project I can look at?

[aeris]

For python, look at coclyclo. For interactive install, look at cozy.

[almet]

Hmm, I'm mostly looking for python-based web servers that are already packaged for debian. From what I understand, Coclyco is "just" a CLI tool, right?

[aeris]

Yep, just a CLI. But no overlap between python and web server for packaging.

[almet]

But no overlap between python and web server for packaging.

What do you mean?

[aeris]

Problem packaging for python are not the same for interactive web server setup. There is no python at all for setup, just plain old bash and nginx vhost deployment.

[JoseAntonioTorre]

Packaging for Debian is just a nightmare. In my work, I have packaged more than 5 packages but I have not uploaded it to Debian repositories. Instead, we have raised our own repository.

The problem is not only related to interactive installing (only this is hard), the problem is that, if you, for example, use a Jquery library in your frontend you should use the official ones packaged from Debian. If you use some Google Analitics you will not pass lintian too.

I know how to start packaging but we in our work are thinking about moving from Debian to another packaging system.

[almet]

Thanks for your input @JoseAntonioTorre! I believe that for this project, using external libraries shouldn't be too hard (but I might underestimate the work here).

If you have the skill to start packaging IHM for debian, that would be very appreciated. I probably can help to overcome some of the issues once this is started, but so far I don't know how to start it all :-)

Out of curiosity : how do you plan to package at your work?

[JoseAntonioTorre]

First, I will try to finish the issues that I am working on and later, I will think about packaging... I hate this part of the work but maybe I can try it.

As for your question, we are raising the idea of using only docker.

[aeris]

You only have trouble with 3rd party if you target to be officially supported by Debian in official repositories. For not official packages, you can include whatever you want.

[JoseAntonioTorre]

But I think you want to be in the official repositories right?

[aeris]

I think it will depends of the difficulty to target Debian Policy compliance…

[almet]

Let's start by packaging it, and then we'll try to resolve the problems to be included officially in debian.

[ChargingBulle]

And doing email validation manually is risky, at best.

the only proper way of doing e-mail verification is by attempting to send an e-mail to the address.

Would you have known that "example@example.com" is legal syntax? Yeah that one is simple. Would you have known that "example@2a02:560:52cb::5d4:4d19:a156" is legal according to e-mail spec (RFC 822)? Would you have known that "example" and "" are also legal?

E-mail verification is done by the mail server. It's not done by the GUI.

[ChargingBulle]

Why was this ticket closed by the way? I would greatly prefer a debian package too. It's one of the most used distros for web servers.

[almet]

You're right @Rick-W-Storm. I'm not sure why I closed this issue, so let's reopen it. If you want to work on this, it would be really helpful to other folks :-)

[Glandos]

If I remember correctly the virtualenv I created, here are the missing package in Debian:

• SQLAlchemy continuum
• Flask Talisman
• SQLAlchemy is now in version 1.4, and we can't get it right now.