About Cozy packaging for ArchLinux

[ArchangeGabriel]

Hi!

I’ve seen recently that they have been a lot of packaging changes around here.

Looking at those change and trying to upgrade to the new packages, I find some things strange.

1. In the way things are packaged now, the cozy package is ending as a almost empty package. I know that since Cozy instances are auto-updating, this package is not really following the upstream Cozy version. In that regard, I have two questions. First, shouldn’t at least some files be part of the package? Like Cozy base files? Or are them all outside standard location, hence that way of doing things? Second, shouldn’t major upgrades (2.0, recently 2.5) be provided by a package upgrade, understanding that dependencies changes occurs at major upgrades, and only minor upgrades be left to auto-updates?
2. In regard to these last questions, I was wondering why I should uninstall my current Cozy to upgrade the package. Indeed, I was running 2.5 flawlessly (at least apparently) with the cozy-nginx package, still depending on nodejs0.10.

Outside of that, it seems that my uninstall didn’t went fine, as they were plenty leftover in couchdb and nginx, some files in /usr/bin (two cozy-something, coffee and cake), and some backup instructions were missing. Which leads me to:

1. The package should not be trying to do that much magic. Install deps, cozy files and nodejs module, and then let the user configure couchdb, his reverse proxy (seems like it’s the case in this new version), etc.

So, I’m currently trying a new install after a full clean, but having some troubles…

[ArchangeGabriel]

Removing the current package let those things on the system: https://gist.github.com/ArchangeGabriel/5ea4d1adb5f8eaa770ad

While I can understand that for coffee, I think that cozy ones should go. And for coffee, maybe a message in remove script.

[ArchangeGabriel]

Also, they are remaining files from auto-enabling some services (couchdb, nginx previously). I think that a package should enable any service. Or even start any. ;)

[babolivier]

Hi @ArchangeGabriel,

First, could you please slow down on the comments and the issue updates? I can't even reply to you before you post something else.

I'm sorry to hear that the uninstall failed. I tried to keep the procedure the smoothest possible in order for the migration to operate well, but it seems from your feedback that it doesn't work for all (as many things in computing). Did you run it with the latest version of the package you were using? (I updated the three packages to "2.0" before releasing the new one) Here are my answers to your questions:

1. The goal of this package is to provide Cozy, not to keep it up to date (that's Cozy's job). That's why the package's version number doesn't match the platform's. The "2.0" is only because the previous one was "1.6" (I was sticking with the Debian package which was at this version at the time) and it seemed like theses major changes required a major update.
   All the "installing Cozy but not handling updates" also explains why we're doing everything from npm installs. My goal is that, even if I don't update the package for a very long time, new installs should run fine, even if many major versions of Cozy got released, with some breaking backward compatibility. All of the Cozy stack is downloaded and installed with NPM at the package's installation. The packages updates only occurs if Cozy's installation process comes to change (or if something's buggy or not working of course), and the only files included are those that don't come with an NPM installation or are specific to the Archlinux port.
2. You can perfectly run the old package. It should work fine, until Cozy starts to use features introduced in Node.js 4.x that won't work with Node.js 0.10. Just note that it's no longer maintained.
3. About the magic thing, you're right, that's what I tried to change with the new package. No more reverse proxy configuration, and other things. I'll improve on this side, eventually.

[babolivier]

Also, please remember that I'm an human, and writing this text while checking my sources is even harder if you paste a list with hundred of files while I'm writing so it's even more painful to scroll up to remember your questions.

[babolivier]

About the remaining files: Yep, I failed a condition (this one) which prevents cozy-monitor to uninstall. Coffee Script should be handled in another package, that's my mistake. I'm fixing them both right now.

[babolivier]

Regarding the services start, CouchDB and Supervisor are essential for Cozy's installation, and they're neede started. And I don't feel like it'd be right to add the full Cozy install (not possible w/out Couch and Supervisor started) in an external script like the domain configuration. It'd be like telling the user: "Hey, congrats on installing an empty shell, here's what to do to manually install what the package was already supposed to install."

[ArchangeGabriel]

Sorry for the disorder, I posted things as long as they were coming. I’ve updated the above comment to move things into a gist.

Hum, maybe we don’t agree here then. I think that a package should not install things or do a lot of magic outside of PKGBUILD.

For me, the cozy package is here for:

1. Dependencies
2. Instructions

I mean, we are Arch users, huge things like that (look at mail programs like smtp/imap servers) are not supposed to be configured OOTB.

[babolivier]

Sorry if I sounded a bit angry (rough day). That's an interesting opinion. I'll look into it. I still may not be as familiar with the way to package stuff for Archlinx as I would. I'm thinking about switching all the installation process as it is (so without reverse proxy and domain name configuration) in an external script so the user can easily run a onestep install, and pointing to the official documentation for the detailed, manual process. What do you think?

[ArchangeGabriel]

@babolivier Don’t worry, my messages seemed probably much more angry, without reason. Rough day here too, but I also have a terrible writing…

That proposal looks really nice. I personally will go with that detailed, manual process.

Also, note that Arch devs are currently trying to remove most of .install scripts, since most of them can now be replaced by hooks. And IMHO, things that cannot be turned into sensible hooks shouldn’t be in a .install script in the first place. ;)

[ArchangeGabriel]

Thinking about it, it would really makes things easier.

New dependencies, nodejs update (I dont know anything about nodejs, so not sure whether this require reinstalling npm things too) → package update.

New install way: install script update. This way, existing installs are not perturbed. Also, this should probably go into a dedicated package, along with the domain name configuration script. Like cozy-install, depends on cozy. Like this, those scripts can even be removed after successful install.

BTW, if you’re the one managing the official ArchLinux doc @cozy:

“In order to run Cozy, we need to install Node.JS v4.x.x (LTS), located in the nodejs-lts-bin AUR package.

Unfortunately, if Node.JS is already installed on your machine with the nodejs official package, a conflict will appear between it and nodejs-lts-bin. All you have to do to solve this issue is hitting "y" (letter can vary according to the system language, but you get it) when the installer asks you if you want to replace nodejs and npm.”

That’s not exactly a good answer. ;) What if the user has nodejs because another program needs it, and especially use 5.x features?

[babolivier]

Well, s.he would have to make a choice, since, as far as I know, Cozy isn't fully compatible with Node.js 5.x. In the doc, I'm explaining how to install the right components for a fully functional Cozy, assuming that, if the user needs a specific version of node, s.he'll know what choice to make or figure how to work around this constraint. If not, well, support is here for this purpose :)

[ArchangeGabriel]

@babolivier Just seen you’ve removed cozy from AUR. Maybe CozyCloud website should be updated then.

For the future of Cozy packaging: I think that the right thing to do is having a package to handle the dependencies and create system users, but have everything else in a wiki page detailing specifics of Arch install vs step-by-step mode from Cozy official doc. I might do it if you want.

[babolivier]

Hi @ArchangeGabriel,

• Yup, after discussing the matter on Cozy's IRC, I decided to fill in a deletion request for the cozy package, because I don't have time to maintain it anymore. I'll try to find some and recreate a valid package. I shall find some time to update Cozy's doc, tho.
• That's exactly what I had in mind, adding maybe a bash script offering to run the whole procedure for the user (like the one first version of the package had as its post_install script). If you have some time ahead and are willing to work on that, I have nothing against that :smile:

[ArchangeGabriel]

I’m closing this, it has become mostly irrelevant with my new package and will be even more in the next version.