Is myphotoshare ready for debian?

[paolobenve]

In order answer yes to the question, #60 has to be solved.

Besides that, I'm wondering if the name can be exposed, a simple search on the web shows many projects with this name... perhaps a new name is needed?

Are there other stuffs which must be addressed?

[pmetras]

Perhaps the geonames.org data should be in a separate shared package. This package could be used by other applications on the computer. The user could decide accessing the web service or the installed data from that package. Also Debian is quite picky about licenses. Geonames data is licenses as CC while MyPhotoShare is using GNU GPL. Perhaps these different licenses mandates 2 different packages. But in that case, we should defined a way or API for MyPhotoShare scanner to access the data...

Yes, perhaps another more sexy name can be useful to attract more user/developers. But when the gallery is installed, I don't look anymore at the name.

[pmetras]

Here is a script to create a Debian package for MyPhotoShare. mps_debian.tar.zip

Just run make_deb.sh script with the MyPhotoShare version you want to build a package, and it'll download it from GitHub, create the documentation and man page, minify the CSS and JavaScript and build the package in the current directory. Example:

./make_deb.sh v3.4beta

As the structure of documentation has changed between v3.3 and v3.4, I'm not sure it can build packages for versions less than 3.4. Usually, all versions should have a debian directory with version-specific package config files, but I've decided to use a common debian directory and try to maintain it for the latest version. This allows to have a full automatic package builder.

I don't plan to create a GitHub project for this scrip as I don't have enough free time to maintain it in the long term. I'm not sure it can be included into MyPhotoShare. It is probably better to have it in a side project where all OS distributions can put stuff to build packages.

The resulting package has been tested on Ubuntu Xenial and seems to work well. It needs to be tested on other Ubuntu and Debian versions.

[anarcat]

for what it's worth, i maintained photofloat as a debian package myself for a while, before i got tired of the project. the debian tree should give you something good to start with...

good luck!

[pmetras]

Thanks Antoine, I'll try to take over where you left. I'm not sure I'll have enough time to push it to Debian repository. I just want to offer it to Debian/Ubuntu users who want to give a try at MyPhotoShare.

[anarcat]

uploading to debian once shouldn't be too hard, provided you find a mentor to do your uploads. the problem is keeping that up to date. ;)

[pmetras]

A philosophical question... MyPhotoShare main command scanner/main.py that I renamed to myphotoshare_scanner in the Debian package, and most other commands, are run in a cron job or at setup time. As such, they are run by root. Does it make sense to place them into /usr/sbin instead of /usr/bin?

I find it strange to have sbin commands when I've been using them as a single user while developing them... As a consequence, cache content will be owned by root.

[pmetras]

In fact, the only command that can be used by a user is make_album_ini.sh (renamed to myphotoshare_make_album_ini in Debian/Ubuntu package).

Do we need to split the recently created bin directory into sbin and bin? Or do we let the packager move the commands to the different locations?

[anarcat]

On 2018-03-07 03:46:06, pmetras wrote:

A philosophical question... MyPhotoShare main command scanner/main.py that I renamed to myphotoshare_scanner in the Debian package, and most other commands, are run in a cron job or at setup time. As such, they are run by root. Does it make sense to place them into /usr/sbin instead of /usr/bin?

Please don't run as root: create a user in the package (and remove it on purge) and use that user for cronjobs.

[pmetras]

I have to read the Debian policy on how to create a dedicated package user. For the moment, the package cronjob runs as root. That's not the safest way... but I won't be able to work on a computer for a few days/weeks and I have to delay that change for now. It'll be my next task when I can access a computer again.

The script to create a Debian/Unbuntu package has been pushed to GitHub https://github.com/pmetras/mps_debian. I can add collaborators to the project if you want to do changes while I'm off. I don't think it's worth creating forks for such a small project. Else wait a few weeks before using it...

[anarcat]

i am sorry but i do not have time to contribute much further here, but thanks so much for the invitation! :)

[pmetras]

I've updated the script creating the Debian package to create the myphotoshare system user.

Now I hope the Debian package is ready and can be used when MyPhotoShare version 3.4 is ready! :1st_place_medal: :sparkles:

[paolobenve]

I was wondering if perhaps it's better to make all the cache files not writable by group, as a way to prevent accidental changes in cache... python should do that

[pmetras]

The new system user myphotoshare that I create in the Debian package is of group nogroup. There should be no problem having the cache files only user-readable. The possibility/impact of a cache file change is already quite low.

[paolobenve]

The issue with js libraries:

On Debian/Ubuntu, installing system-wide JavaScript packages like jquery seems not to be enough, at least with apache2: sudo a2enconf javascript-common (followed by sudo service apache2 reload) must be run on the server to enable the use of /javascript virtual directory.

The install script should run a2enconf javascript-common && service apache2 reload if any of the optional js libraries is installed

[pmetras]

I would expect the javascript-common package doing Apache configuration by itself, but that's not the case. I'll add it to the Debian package for MyPhotoShare. Thanks