cleaning

[ericgaspar]

Problem

• Description of why you made this PR

Solution

• And how do you fix that problem

PR Status

• [ ] Code finished and ready to be reviewed/tested
• [ ] The fix/enhancement were manually tested (if applicable)

Automatic tests

Automatic tests can be triggered on https://ci-apps-dev.yunohost.org/ after creating the PR, by commenting "!testme", "!gogogadgetoci" or "By the power of systemd, I invoke The Great App CI to test this Pull Request!". (N.B. : for this to work you need to be a member of the Yunohost-Apps organization)

[ericgaspar]

!testme

[yunohost-bot]

Meow :cat2:

[ericgaspar]

!testme

[yunohost-bot]

:stuck_out_tongue_winking_eye:

[rodinux]

Hello, not sure with all these changes. The users are supposed to make configs changes, the idea was to

• keep a clean file with the parameters need with yunohost and not touch this one config.local.yunohost.php (the secret key is here, the values by default needed on yunohost),
• the file config.local.user.php is the file where the user need to add personal parameters (there's a lot of configs avalaible, wabdav sunc, dir for data folder, nextcloud sync, whtlmtopdf, etc...),
• The file config.local.php is the first read, so we put links to read the two others files here. I think it is better keep them to keep the personal configurations...

Then, I just understand that the better way to upgrade the app is to unzip it on a blank directory, normaly you do that in another directory, I don't how to do this so I backup all th files need to be backup on the folder data, also the BDD, association.squlite is there. I thought the solution was keep this folder on a tmp folder, then force an unzip (install) with nothing more inside, --replace=1 to force this, then put back the files backup with a rsync... It is possible also that users have download plugins in this folder... It is why I think also the better way to keep all datas and the personal configuration config.local.user.php in the folder data is the more simple....

I am ok to add some of you're suggestion, also the cron, but I doubt with the others changes...

[rodinux]

If you do that, erasing the --full_replace=1 and use keep= for ynh_setup-source, we come back to old method install which made some errors... I have made a lot of tests and exchange with the developer @BowazH about. The clean method to do an updgrade, if it wasn't in a Yunohost environment, is to unzip in another blank folder the source, add later the folder data, beacause in this one you have the BDD file, the folders for plugins, perhaps for files added if you have choice keep your files in a folder, etc...

If I we want use keep= it should be be config.local.php data, but this make errors sometimes, also there was a folder unused duplicated data on lot of older upgrades.. It is the reason of why I have try another way to keep backups of this folder and files on temp store, and unzip the app with a full_replace...

Perhaps I am on the wrong way... It is important also to understand that this install and upgrade is only a pre-install process, the installation is after a register process...

[ericgaspar]

Ok, thanks for the explanations, I let you manage the app. Closing

[alexAubin]

eric's PR was however very much legit ... I think we are well-aware of why you ended up with the --full-replace and the whole thing with the data folder, which is related to the fact that the data live "inside" the install dir

The point of eric's PR was precisely to have the data folder to another location, which is more convenient and semantic in many ways, including the fact that you dont have to perform all the weird backup anymore, and that it allows for stuff such as "computing how much the source weight" versus "computing how much the data weight" ...

Same goes for the config.local.php (which can be handled using the --keep option ...), i don't see the benefit of having a .yunohost and a .user ... having a single conf file and stick to what the upsteam does sounds more straightforward to understand ...

[rodinux]

eric's PR was however very much legit ... I think we are well-aware of why you ended up with the --full-replace and the whole thing with the data folder, which is related to the fact that the data live "inside" the install dir

The point of eric's PR was precisely to have the data folder to another location, which is more convenient and semantic in many ways, including the fact that you dont have to perform all the weird backup anymore, and that it allows for stuff such as "computing how much the source weight" versus "computing how much the data weight" ...

Same goes for the config.local.php (which can be handled using the --keep option ...), i don't see the benefit of having a .yunohost and a .user ... having a single conf file and stick to what the upsteam does sounds more straightforward to understand ...

Ok, may be is a better way, I don't want stop the help with yours competence or rather continue understand your suggestions. The script upgrade have done some strange unwanted things sometimes.

How works the way for keep the folder data in another location here ?

Ok to keep only the file config.local.php and keep it every upgrade, the problem was how this file change sometimes (I mean new lines with new functions can appear with releases).

Can we reopen this PR ? We need make some tests also...

[rodinux]

Ok, may be is a better way, I don't want stop the help with yours competence or rather continue understand your suggestions. The script upgrade have done some strange unwanted things sometimes.

How works the way for keep the folder data in another location here ?

Ok to keep only the file config.local.php and keep it every upgrade, the problem was how this file change sometimes (I mean new lines with new functions can appear with releases).

Can we reopen this PR ? We need make some tests also...

@ericgaspar is it possible reopen this work ? I am confused...