On Thursday 2015-04-30 16:42, Greg Freemyer wrote:

On Tue, Apr 28, 2015 at 7:45 PM, Jan Engelhardt <jengelh@inai.de> wrote:

...

On Wednesday 2015-04-29 01:04, Greg Freemyer wrote:

...

My SR to add a couple of generic "Requires:" to the wordpress spec file has been rejected because they are generic: Can someone explain to my why the use of

Requires: httpd Requires: mod_php_any

[... consider] php-fpm.

To close the loop on this, I did the SR as a Recommends and the SR was accepted.

Aha. I would have just removed them altogether. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 04/30/2015 03:30 PM, Greg Freemyer wrote:

On Thu, Apr 30, 2015 at 5:08 PM, Jan Engelhardt <jengelh@inai.de> wrote:

...

On Thursday 2015-04-30 16:42, Greg Freemyer wrote:

...

On Tue, Apr 28, 2015 at 7:45 PM, Jan Engelhardt <jengelh@inai.de> wrote:

To close the loop on this, I did the SR as a Recommends and the SR was accepted.

Aha. I would have just removed them altogether.

And potentially break wordpress for the 99% of users that run it on the same machine as Apache.

Or is it common to run wordpress on one machine and Apache on a different one?

Greg

I don't know that it is so much this issue, more the idea that Apache is not actually required for Wordpress. PHP, MySQL and some sort of workable web server are. 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. With a package, the install process is install package, then configure a DB and web server. -- Jason Craig -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi Jason, 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.

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. Every piece of software on a system should be a package. I can't believe anyone is arguing against that. -- 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

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

On Tue, Apr 28, 2015 at 7:57 PM, Yamaban <foerster@lisas.de> wrote:

On Wed, 29 Apr 2015 01:04, Greg Freemyer wrote:

...

All,

My SR to add a couple of generic "Requires:" to the wordpress spec file has been rejected because they are generic:

https://build.opensuse.org/request/show/304469

My re-opened SR was also rejected.

Can someone explain to my why the use of

Requires: httpd Requires: mod_php_any

is wrong. I know the below will also work, but I don't see why we should be restrictive

Requires: apache2 Requires: apache2-mod_php5

That is unless wordpress is strictly a apache2 based tool, but I can't imagine that is true.

fyi: In the SR Eric did say:

"httpd only for other than opensuse."

I don't understand that since apache2, lighttpd and nginx all provide httpd in their opebnsuse packages.

He also said "zypper se php_mod_any" show "package not found"

That is true, but "zypper se" doesn't search for generic provides so that logic would invalidate all use of generic requires.

Foreword: I'm no guru, god, or any other "last-instance", but on a few things, I can shed a little light on:

First: the package apache2 provides "apache2", "httpd" and "http_daemon" (https://build.opensuse.org/package/view_file/Apache/apache2/apache2.spec?exp...)

fyi: you can get a more definitive list of provides by going to the main package page: https://build.opensuse.org/package/show/Apache/apache2 Click on the distro you care about. (say 13.2). https://build.opensuse.org/package/binaries/Apache/apache2?repository=openSU... You get a list of RPMs. Then click on the RPM you care about, say apache2-2.4.12-6.1.i586.rpm You get a list of all the provides and requres. https://build.opensuse.org/package/binary/Apache/apache2?arch=i586&filename=apache2-2.4.12-6.1.i586.rpm&repository=openSUSE_13.2 For each provide you get a list of which packages in the repo the rpm is built for requires that provide. For each require you get a list of which packages in the repo the rpm is built for can satisfy the require.

Second: the main package php5 provides sub-packages: apache2-mod_php5: Provides: "mod_php_any", "php-session" fastcgi: Provides: "php-cgi", "php-fastcgi", "php-session" (https://build.opensuse.org/package/view_file/devel:languages:php/php5/php5.s...)

Third: if using zypper to search, do it right: zypper search --provides {requirement}

so here you "require" either:

for openSUSE / SLE: "apache2" and "apache2-mod_php5"

and for Fedora / Redhat: "httpd" and "mod_php_any"

So httpd and mod_php_any are Redhat specific identifiers?

with a constuct of:

%if 0%{?suse_version} Requires: apache2 Requires: apache2-mod_php5 %else Requires: httpd Requires: mod_php_any %endif

or you go full generic, any http server, any php server modul: "http_daemon" and "php-session"

I guess that is my question. Where is a list of full generic identifiers?

Requires: http_daemon Requires: php-session

I prefer the full generics, but I'll go with the Apache specific just to get this done. Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org