Hi Jason, On Tue, 05 May 2015 10:39:42 -0600, Jason Craig wrote:
On 05/05/2015 10:05 AM, Jean Delvare wrote:
Le Thursday 30 April 2015 à 16:40 -0600, Jason Craig a écrit :
Personally I'm not sure why something like this is bothered to be packaged, and I wonder what the size of the user base that you mention is. There is no build. The installation process is beyond simple: untar, then configure a DB and web server.
You forgot the first two steps: find where the tarball is on the interet, and download it. So that's 5 steps vs. 3, and your approach no longer sounds so attractive.
OK, if we are going to be pedantic, then the RPM way has two additional steps as well in 1) find the repository the package is in 2) set up that repository in your package manager.
Ah, my bad, I thought it was in the default repository. If not then indeed both approaches take the same time to install.
With a package, the install process is install package, then configure a DB and web server.
Then think about updates. With a proper package, this can be automated and controlled. With your approach, it's all manual, or most likely never done, or not in a timely manner.
Well with the actual software in question (WordPress), updates are installed automatically and transparently as users access the web frontend. This can happen as soon as the new sources are available upstream. The RPM package gets updated sometime after these sources are available (probably by a person), and that updated package gets installed sometime after that. So in fact the non-RPM way probably will get the update in a more timely fashion.
I see. From a security perspective, software which updates itself doesn't sound good. Not only because you may not control when this happens, but more importantly because the fact that the running process is _allowed_ to write to its own code means that any security issue in that application will give attackers the ability to change the application to do whatever they want. For reasonable security, a web application should only ever be able to manipulate data, not its own code. You will have noticed for example that Firefox under Windows will propose to update itself, but we disabled this functionality in openSUSE. This is because we have a clear separation between roles. Users aren't administrators. We want to control what goes to the update channel, and when it goes there (after it has been tested to some degree.) Sure, some users would probably want to have some of the updates faster and our process induces some delay. But overall the user experience is certainly better this way, as it avoids a lot of regressions too. Just go back to Windows for a day and see Flash, Acrobat, Java, Firefox etc. all ask you if you want to update, one after the other, and you'll see what I mean. In openSUSE (and GNU/Linux in general) we have a centralized update system, which is more admin and user friendly. And a lot safer.
Every piece of software on a system should be a package. I can't believe anyone is arguing against that.
But what about the (extremely common) use case in which more than one instance of this package needs to be installed? With nearly every web application it is perfectly reasonable to have multiple instances in use on one (virtual) machine. This is not the case with almost any desktop application, and when it is the case, it usually is two different versions (Python2 vs. 3, GCC 4 vs. 5) and not the same version multiple times, as it is with web applications.
Multiple instances running should not imply multiple installations. If web software works like that these days, well, it's broken by design, sorry. I can't really make sense of the logic, I'm afraid. On the one hand, you want updates to be applied automatically as soon as possible. But on the other hand, you want a separate installation for each instance. The only reason that can justify this from a production perspective is that you want to be able to update the different instances at different times. But if you need to do that, it implies that automatic and immediate updates aren't so desirable. And then a package-based installation would serve you better. In my very humble and uninformed opinion.
Look, I have no problem if people want to package these types of things, nor if there are people who use said packages. I simply find the package to be insufficient for most of the workflows I have used this type of application for as well as not providing any added benefit that I have been able to utilize. It probably would be great if everything were a package, but if package management doesn't handle all the use cases for web applications, then one simply can't use it for those cases.
It is entirely possible that the way we package these applications is suboptimal for some setups. Maybe this can be improved easily, or maybe the way these web applications were designed to run and update is just flawed and that would need to be fixed first. To be honest I didn't look into it, and won't, as I have little interest in this at the moment. What I can tell you is that if am ever responsible for putting web applications in production, they will be packaged, no matter what it takes. -- Jean Delvare SUSE L3 Support -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org