On Saturday 2019-07-06 10:59, Eric Schirra wrote:

Am Samstag, 6. Juli 2019, 02:27:02 CEST schrieb Stasiek Michalski:

...

Hi,

I was playing around with my server today, having some fun with setting up some services on it, and I noticed that nextcloud requires apache2 for no particular reason. So I went to mess with some specs. For quite some time I wanted to switch packaging around, as /srv should stay reserved for user needs and not packaging. If I understand you correctly, you want software no longer on / srv, but under /usr. I do not like this idea at all. I would like to continue to see server software under /srv.

/srv is _defined_ by FHS in the same spirit to /home. Asking for software be installed in /srv is like asking for software be installed in /home (which is ridiculous).

In addition, I always work with console on console. So I have no desire to work with cd and so on.

"Wash me but don't make me wet"?

Furthermore, I find it extremely annoying when I install a software as a pact and then does not run at all and I have to read the installation instructions of the developers. Then I do not need a package.

Great, then you are not even a user affected by the proposed change. (Even if something lives in /usr, it can be made to behave as if it were present in /srv as far as a web server is concerned. kopano-webapp.spec does that for example.)

PS: Even if that does not belong in this thread. I think there are more important things / problem to solve in openSUSE. For example, Ancient packages and libraries, just because they are in SLE. :-(

Well, if you think those topics are important, you are free to work on them, just as Stasiek is free to work on issues he considers important. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 07/07/2019 03:38, Eric Schirra wrote:

Am 6. Juli 2019 11:56:51 MESZ schrieb Jan Engelhardt :

...

On Saturday 2019-07-06 10:59, Eric Schirra wrote:

...

Am Samstag, 6. Juli 2019, 02:27:02 /srv is _defined_ by FHS in the same spirit to /home. Asking for software be installed in /srv is like asking for software be installed in /home (which is ridiculous).

No it is not. Home only for user things. Srv for "world". See links in my other post.

...

...

Furthermore, I find it extremely annoying when I install a software as a pact and then does not run at all and I have to read the installation instructions of the developers. Then I do not need a package.

Great, then you are not even a user affected by the proposed change.

of course. I use nextcloud myself and want to keep this in srv. Incidentally, I'm a maintener bn nextcloud and one of those who makes sure that the package is up to date and also updates every update without any action. which is not the case with many web applications.

...

(Even if something lives in /usr, it can be made to behave as if it were present in /srv as far as a web server is concerned. kopano-webapp.spec does that for example.)

and that bothers me. I have to look under a hundred folder that of kopano. under srv there are nextcloud and two or three others and ready

...

...

PS: Even if that does not belong in this thread. I think there are more important things / problem to solve in openSUSE. For example, Ancient packages and libraries, just because they are in SLE. :-(

Well, if you think those topics are important, you are free to work on them, just as Stasiek is free to work on issues he considers important.

and what shall I do? all attempts to bring new package versions or current versions of libraries and applications in leap 15.1 failed. always on the grounds that comes from sle. more attempts were dismissed, which even once went almost so far that I should be blocked. Since then I do not do anything for leap. As a "small" packager and user at opensuse I have no management at all to do this. I am synonymous with stability, which is why I also use leap and tumblweed. if that goes so far, the desktop programs nei a new leap vetsion are clearly slt, then that goes too far. opensuse itself with such old desktop apps even no favor. see also the comments on the web. Among other things, it has never been so quiet on the web at 15.1. I wonder why?

I think your missing the point of Leap, Leap is meant to be stable and boring, its meant to keep the same or a very similar base system for most of its lifecycle, it intentionally doesn't get the newest everything stuff is only upgraded if there is a really good reason, this is what some openSUSE users want. For people who want the latest stuff tumbleweed is a far better option. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, Am 07.07.19 um 10:07 schrieb Simon Lees:

I think your missing the point of Leap, Leap is meant to be stable and boring, its meant to keep the same or a very similar base system for most of its lifecycle, it intentionally doesn't get the newest everything stuff is only upgraded if there is a really good reason, this is what some openSUSE users want. For people who want the latest stuff tumbleweed is a far better option.

not sure if this is the correct thread and location (actually I think it's not) but this is actually an interesting topic. Specifically since 15.1 I had the feeling that SUSE "dictates" a bit too much what gets into Leap and what is not. There are examples where updates were dismissed because SLE 15SP1 has a certain package and didn't want to upgrade or packages which are taken over by SLE15 variants which were a fork before. I am not sure if all those decisions have been completely agreed inbetween the openSUSE community packager and SUSE. At the same time I'm all in for compatibility between Leap and SLE and also to make maintenance easier for the community if something is maintained by SUSE but all that is very fine line in my opinion and I have the light feeling that it tends to get stretched a bit far into the SLE direction. This is probably just my perspective for the stuff I'm somehow involved in. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 8 Jul 2019 at 11:36, Hans-Peter Jansen wrote:

Am Montag, 8. Juli 2019, 09:30:06 CEST schrieb Wolfgang Rosenauer:

...

Hi,

Am 07.07.19 um 10:07 schrieb Simon Lees:

...

I think your missing the point of Leap, Leap is meant to be stable and boring, its meant to keep the same or a very similar base system for most of its lifecycle, it intentionally doesn't get the newest everything stuff is only upgraded if there is a really good reason, this is what some openSUSE users want. For people who want the latest stuff tumbleweed is a far better option.

not sure if this is the correct thread and location (actually I think it's not) but this is actually an interesting topic. Specifically since 15.1 I had the feeling that SUSE "dictates" a bit too much what gets into Leap and what is not. There are examples where updates were dismissed because SLE 15SP1 has a certain package and didn't want to upgrade or packages which are taken over by SLE15 variants which were a fork before. I am not sure if all those decisions have been completely agreed inbetween the openSUSE community packager and SUSE.

There is a process for raising concerns in this project when one maintainer disagrees with another. That is when the openSUSE Board should be contacted by the aggrieved parties. As far as I can recall, there has never been a single concern raised by a non-SUSE employed contributor about the SLE/Leap decisions of a SUSE employed contributor, or visa versa. So, while I'm not naive enough to be surprised by your point, I am highly disappointed that you and any others who feel the same as you feel that griping in a public mailinglist is preferable to raising your concerns to the very body that exists for when different contributors disagree on the nature of their contributions.

Yes, it could lead to somewhat grotesque situation, where a fix to a *dysfunctional* package takes more than half of the distributions *lifetime*.

https://bugzilla.novell.com/show_bug.cgi?id=1099874

If you want fast moving changes, use Tumbleweed. The fact that all changes to Leap after release are deliberate and very carefully examined and thoroughly worked through is a positive, not a negative of the SLE/Leap dynamic. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Richard, Am 08.07.19 um 13:40 schrieb Richard Brown:

On Mon, 8 Jul 2019 at 11:36, Hans-Peter Jansen wrote:

...

Am Montag, 8. Juli 2019, 09:30:06 CEST schrieb Wolfgang Rosenauer:

...

Hi,

Am 07.07.19 um 10:07 schrieb Simon Lees:

...

I think your missing the point of Leap, Leap is meant to be stable and boring, its meant to keep the same or a very similar base system for most of its lifecycle, it intentionally doesn't get the newest everything stuff is only upgraded if there is a really good reason, this is what some openSUSE users want. For people who want the latest stuff tumbleweed is a far better option.

not sure if this is the correct thread and location (actually I think it's not) but this is actually an interesting topic. Specifically since 15.1 I had the feeling that SUSE "dictates" a bit too much what gets into Leap and what is not. There are examples where updates were dismissed because SLE 15SP1 has a certain package and didn't want to upgrade or packages which are taken over by SLE15 variants which were a fork before. I am not sure if all those decisions have been completely agreed inbetween the openSUSE community packager and SUSE.

There is a process for raising concerns in this project when one maintainer disagrees with another. That is when the openSUSE Board should be contacted by the aggrieved parties.

As far as I can recall, there has never been a single concern raised by a non-SUSE employed contributor about the SLE/Leap decisions of a SUSE employed contributor, or visa versa.

So, while I'm not naive enough to be surprised by your point, I am highly disappointed that you and any others who feel the same as you feel that griping in a public mailinglist is preferable to raising your concerns to the very body that exists for when different contributors disagree on the nature of their contributions.

for me personally there was never the point where I had a reason to call for some institution to resolve the situation. I only read this thread and felt like I raise some concerns before they might get more and because it seems that others were hit more before. I can tell about my experiences as a maintainer of some packages that the way how to request an update for a package inherited from (or switched to) SLE is not very clear, it's very strange because you get e.g. asked by someone corporate what is the business case for an update (example on request) and other weird discussions. As said for me it worked out acceptable. But there are certainly strange situations happening like for example Firefox which was a fork until Leap 15.0 and was pushed from SLE to Leap 15.1 and now is managed from there. I was a bit involved into a discussion before and I (think I) understand where that is coming from but the result as could be seen a few weeks ago was quite strange when the current 15.1 package was older than the 15.0 one and broken as well. In any case those experiences together with reports from others just paints a picture in my mind where I see some misalignment. I'm not saying we are there yet but the direction is to something like: Leap = SLE + community stuff What I think that Leap should be: Leap = SLE (with community modifications where the community/maintainer wants it; in best case w/o breaking base compatibility with SLE) + community stuff Now the truth is probably somewhere inbetween and that is what I meant with "dictates a bit too much". And that is certainly a topic for a mailing list and not a personal discussion with the board. You can argue that I continued on opensuse-factory instead of moving to opensuse-project right away though. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, Am 09.07.19 um 14:17 schrieb John Paul Adrian Glaubitz:

On 7/8/19 2:14 PM, Wolfgang Rosenauer wrote:

...

In any case those experiences together with reports from others just paints a picture in my mind where I see some misalignment. I'm not saying we are there yet but the direction is to something like: Leap = SLE + community stuff What I think that Leap should be: Leap = SLE (with community modifications where the community/maintainer wants it; in best case w/o breaking base compatibility with SLE) + community stuff

Now the truth is probably somewhere inbetween and that is what I meant with "dictates a bit too much".

Well, SLE dictates - and enterprise Linux in general - the direction because that's where the vast majority of users are. I know that most people do not like to hear this, but Linux has nearly no relevance on the desktop so it's just natural that the server variants determine the direction as they are also the ones who are funding most of the development (be it Red Hat, SUSE, Intel, Google, IBM etc).

If you want that developers are being paid to work on Linux and open projects in general, you have to accept the fact that most customers who are paying these developers are enterprise customers in the end.

I'm not arguing against what you wrote but it just does not matter here. We are talking about openSUSE Leap and not about SUSE LINUX Enterprise. If Leap is SUSE controlled it should be named SUSE Leap or SUSE CentOS or whatnot leaving openSUSE out. Having worked for SUSE, have been running openSUSE Evergreen, maintaining almost all Mozilla stuff in SUSE/openSUSE since almost 20 years, working for an OSS company you do not need to tell me that story. Since this thread is kind of off-topic and probably even not very efficient because to abstract I'll shout again directly the next time I see that sort of misalignment. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 7/9/19 3:08 PM, Richard Brown wrote:

Well said. For the record, I disagree with some of Johns sentiment. and feel it is not consistant with the official opinion of SUSE.

It's Adrian, not John ;). And I'm not sure where I'm wrong, the numbers speak for itself:

https://go.pardot.com/l/6342/2017-10-24/3xr3f2/6342/188781/Publication_Linux... http://gs.statcounter.com/os-market-share

I know it's very controversial to say that among the community but in the end, it's pretty much what the numbers say.

The community is the only entity that controls what is inside Leap, with the obvious caveat that SUSE is part of that community also.

The community doesn't have the manpower to work on projects like the kernel, gcc or anything of similar size. In the end, there is always a corporate entity which is funding the work. Even a large number of Debian developers are paid by a company, in many cases Canonical. And Debian is legally a completely independent project, yet there are companies behind it driving the development. Free software doesn't mean developers work free of charge. Adrian N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�

On 08/07/2019 21:44, Wolfgang Rosenauer wrote:

Hi Richard,

Am 08.07.19 um 13:40 schrieb Richard Brown:

...

On Mon, 8 Jul 2019 at 11:36, Hans-Peter Jansen wrote:

...

Am Montag, 8. Juli 2019, 09:30:06 CEST schrieb Wolfgang Rosenauer:

...

Hi,

In any case those experiences together with reports from others just paints a picture in my mind where I see some misalignment. I'm not saying we are there yet but the direction is to something like: Leap = SLE + community stuff What I think that Leap should be: Leap = SLE (with community modifications where the community/maintainer wants it; in best case w/o breaking base compatibility with SLE) + community stuff

What we have at the moment is close to 3, if you substitute "community/maintainer" with "community maintainer", ie if there is someone in the community who is willing to maintain it then they can have the discussion with the SUSE maintainer as they will be working together co maintaining the package anyway, for build system and core libraries or other packages that end up affecting other packages the answer is still more likely to be no, but for some packages that effect less other things or some groups of packages it is possible. However the community wanting something updated and not doing it themselves is less likely to happen, that would probably be asking the SUSE maintainer to do additional work in there spare time, and one of the core principles of openSUSE is that we don't ask people to do additional work, they do it if they feel like it. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10/07/2019 15:37, Wolfgang Rosenauer wrote:

Am 10.07.19 um 02:27 schrieb Simon Lees:

...

On 08/07/2019 21:44, Wolfgang Rosenauer wrote:

...

In any case those experiences together with reports from others just paints a picture in my mind where I see some misalignment. I'm not saying we are there yet but the direction is to something like: Leap = SLE + community stuff What I think that Leap should be: Leap = SLE (with community modifications where the community/maintainer wants it; in best case w/o breaking base compatibility with SLE) + community stuff

What we have at the moment is close to 3, if you substitute "community/maintainer" with "community maintainer", ie if there is someone in the community who is willing to maintain it then they can have the discussion with the SUSE maintainer as they will be working together co maintaining the package anyway, for build system and core libraries or other packages that end up affecting other packages the answer is still more likely to be no, but for some packages that effect less other things or some groups of packages it is possible. However the community wanting something updated and not doing it themselves is less likely to happen, that would probably be asking the SUSE maintainer to do additional work in there spare time, and one of the core principles of openSUSE is that we don't ask people to do additional work, they do it if they feel like it.

Yes, we are somewhere inbetween in general with some trend in one or the other direction. I was pretty satisfied with Leap 42 and more or less still with 15.0. With 15.1 it already felt more towards the first. In any case you are spending half of your mail talking about updates. If that refers to an earlier mail from me in that thread then I need to add that I never asked anyone to do an update for a package for me. In most cases I am the maintainer (or at least co-maintainer or major contributor) of those packages I'm asking for anyway and I wanted to have them updated (typically) to Factory level. And exactly that process felt quite weird.

Yeah in this term I meant updates from what the previous version had rather then specifically maintenance updates. Whenever we do such an update in SLE, it also leads to more work for SUSE maintainers because then whenever we need to fix a security issue we need to fix it for the new and older versions, Packages in SLE service packs also have a much longer lifetime then Leap especially if they are core packages with LTSS support, so for packages that we do decide need frequent updates its not uncommon to need to do 5-6 maintenance updates for different versions to fix one security update. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/07/2019 17:10, Wolfgang Rosenauer wrote:

Hi,

Am 11.07.19 um 04:11 schrieb Simon Lees:

...

On 10/07/2019 15:37, Wolfgang Rosenauer wrote:

...

Am 10.07.19 um 02:27 schrieb Simon Lees:

...

What we have at the moment is close to 3, if you substitute "community/maintainer" with "community maintainer", ie if there is someone in the community who is willing to maintain it then they can have the discussion with the SUSE maintainer as they will be working together co maintaining the package anyway, for build system and core libraries or other packages that end up affecting other packages the answer is still more likely to be no, but for some packages that effect less other things or some groups of packages it is possible. However the community wanting something updated and not doing it themselves is less likely to happen, that would probably be asking the SUSE maintainer to do additional work in there spare time, and one of the core principles of openSUSE is that we don't ask people to do additional work, they do it if they feel like it.

Yes, we are somewhere inbetween in general with some trend in one or the other direction. I was pretty satisfied with Leap 42 and more or less still with 15.0. With 15.1 it already felt more towards the first. In any case you are spending half of your mail talking about updates. If that refers to an earlier mail from me in that thread then I need to add that I never asked anyone to do an update for a package for me. In most cases I am the maintainer (or at least co-maintainer or major contributor) of those packages I'm asking for anyway and I wanted to have them updated (typically) to Factory level. And exactly that process felt quite weird.

Yeah in this term I meant updates from what the previous version had rather then specifically maintenance updates. Whenever we do such an update in SLE, it also leads to more work for SUSE maintainers because then whenever we need to fix a security issue we need to fix it for the new and older versions, Packages in SLE service packs also have a much longer lifetime then Leap especially if they are core packages with LTSS support, so for packages that we do decide need frequent updates its not uncommon to need to do 5-6 maintenance updates for different versions to fix one security update.

ok, you are describing yet another specific situation. When I want a package updated in Leap as part of a new minor release I sometimes do not care what happens in SLE. (Obviously this depends a bit how deep that package lives in the system.) I'm caring about the package anyway and I want Leap users to get that for certain reasons. I'm willing to do the maintenance in those cases as well. But there seems to be resistance of having forks.

Let's use a specific example to illustrate one (not sure if the bugreport is visibile for everyone but at least for SUSE people it is).

Thanks, specific examples are good (especially this one), the bug should be public but its not because someone wrongly locked it to partners.

This example will be a bit longer though:

So talking about Mercurial: wolfi@Hygiea:~> osc maintainer mercurial Defined in package: devel:tools:scm/mercurial bugowner of mercurial : wrosenauer

maintainer of mercurial : wrosenauer, develop7

So both people listed here do not work for SUSE. The package is inherited from SLE15 (mercurial: SUSE:SLE-15:GA).

Here is the first issue, if a package is in SLE one of the bugowners must be a SUSE employee, they should be co maintaining the package with you and you should be able to have this discussion with them and life should be smoother. Maybe its not the case here because we were trying to drop it from SLE, but i'll follow that up with the right people inside SUSE.

I thought mercurial is a good example which should get an update within a minor release and so I requested that in https://bugzilla.suse.com/show_bug.cgi?id=1123391

Here I agree it does seem reasonable.

This is kind of weird discussion and I do not even fully understand it. Especially I still understand that mercurial is required to be in SLE15. What I do not understand though is why SLE15 and Leap MUST have the same version. If that is the case and for some reason a technical hard requirement then fine for me and that is why I didn't bother that much.

This is where it gets interesting. Mercurial is apparently used for building other packages, what should have happened is we should have checked how this works in more detail, if something is just calls the "hg" command to extract some meta data and that output hasn't changed updating it should be fine. However if it uses hg for something more in depth and an update to Mercurial in Leap would cause other packages using it for there build to generate different rpm's in some way then that would be a good reason to keep it the same. But this is much more likely for a tool like cmake or meson.

But this situation leads to the fact that I personally (most likely) will not care if something needs to be fixed in that old package version.

One of the reasons you should have a SLE employee as a co maintainer is because you can't actually fix something in that old package version it needs to go through SLE's maintenance process because the package currently comes from SLE. Thanks for bringing up this example, its a case where the process we should have still isn't working right, if you or anyone else knows of any other examples where this isn't working properly let me know and we will try and sort those out as well. Especially cases where anyone who doesn't work for SUSE is maintaining a package in tumbleweed that is also in SLE and hasn't had contact with the person who should be maintaining it in SLE. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

There is a process for raising concerns in this project when one maintainer disagrees with another. That is when the openSUSE Board should be contacted by the aggrieved parties.

How easy would it be to have a bot add a message pointing out the availability of this process 3 months after SLE has been mentioned in an openSUSE bug and it is still open? Or alternatively the bot could bring such bugs to the attention to the board directly.

...

[...] a *dysfunctional* package [...] If you want fast moving changes, use Tumbleweed.

For the eric5 example, an idea might be to introduce an application- independent test whether the application is still running after a minute and to apply this test to a long list of applications (anything that shows a GUI window, asks interactive questions on the command line or waits for input). Joachim 12 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

PS: Even if that does not belong in this thread. I think there are more important things / problem to solve in openSUSE. For example, Ancient packages and libraries, just because they are in SLE. :-(

I tend to confront standards (so openSUSE works well with software that follows them) like FHS rather than fixing older packages, there are probably people that would be more interested about that stuff than me :D LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On sob, 6 lip, 2019 at 7:45 PM, Eric Schirra wrote:

Am 6. Juli 2019 18:01:25 MESZ schrieb Stasiek Michalski :

...

...

PS: Even if that does not belong in this thread. I think there are more important things / problem to solve in openSUSE. For example, Ancient

...

packages and libraries, just because they are in SLE. :-(

I tend to confront standards (so openSUSE works well with software that follows them) like FHS rather than fixing older packages, there are probably people that would be more interested about that stuff than me :D

When i read fhs. The directory /srv is definitv the right place for webapplication and not /var or /usr or something else. See: https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/srv.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/htm...

It's a great place for user's self maintained data that is supposed to be served by a server. Distributors can install there, but keeping it for users seems like a more reasonable way to go, if we don't __have to__ install there.

Also for backup it is better all web applications are in one dir.

For backups it's better if packages aren't mixed with user configuration data. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On sob, 6 lip, 2019 at 1:49 PM, Carlos E. R. wrote:

On 06/07/2019 02.27, Stasiek Michalski wrote:

...

Hi,

I was playing around with my server today, having some fun with setting up some services on it, and I noticed that nextcloud requires apache2 for no particular reason. So I went to mess with some specs. For quite some time I wanted to switch packaging around, as /srv should stay reserved for user needs and not packaging.

It's easy to set up random sub pages and stuff manually with default apache/nginx configs when /srv is empty, however when it is also used for packaging, it makes unnecessary amount of mess in there, when default configuration could be solved with apache/nginx configs shipped with packages themselves. Don't get me wrong, I like when I install software and it instantly works, but this doesn't really require server software to be installed in /srv, it could work as well in /usr directories.

...

I understand that software is not installed on /srv, but files that can be served by the package, or the directory structure. That is so with apache, which installs /srv/www. Maybe you mean cgi-bin?

I would prefer if applications that absolutely required /srv used it as /home, installed stuff on the first run and managed themselves as far as those things go. I have nothing against packages using the directory, but packaging into it is not something I'm particularly happy about. Although, I can tell this is wishful thinking already, there will always be packages that won't work with the schema, but there is no harm in trying ;)

...

This is the list of src packages that install to /srv (gathered using dnf, because zypper can't get remote file list *grumble grumble*): adminer apache2

...

...

dnsmasq

cer@Telcontar:~> rpm -ql dnsmasq | grep srv /srv/tftpboot cer@Telcontar:~>

But it is only that directory which will store files the admin puts there to be served. Software is not installed on /srv. It is data.

From my user perspective, this is good.

LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org