[opensuse-factory] sles?
Hello, Syslog-ng 3.1.2 was released yesterday, so I started to prepare a version update, as it will make almost all patches redundant. I did a bco, updated syslog-ng, checked in, and found, that it compiles fine on all openSUSE versions, but fails to compile on SLES 11 SP1. Actually, it compiles, but the checks fail, for details check https://build.opensuse.org/package/live_build_log?arch=i586&package=syslog-n... Two questions: 1.) does it need to be able to build sles11 packages, or it is not a requirement to be able to sr it to factory? 2.) could anyone with access to SLES 11 SP1 check, why this happens? Bye, CzP -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Donnerstag, 5. August 2010 21:23:42 schrieb Peter Czanik:
Hello, Hello!
Syslog-ng 3.1.2 was released yesterday, so I started to prepare a version update, as it will make almost all patches redundant. I did a bco, updated syslog-ng, checked in, and found, that it compiles fine on all openSUSE versions, but fails to compile on SLES 11 SP1.
Actually, it compiles, but the checks fail, for details check https://build.opensuse.org/package/live_build_log?arch=i586&package=syslog- ng&project=home%3Aczanik%3Abranches%3ABase%3ASystem&repository=SLE_11_SP1
Two questions:
1.) does it need to be able to build sles11 packages, or it is not a requirement to be able to sr it to factory?
2.) could anyone with access to SLES 11 SP1 check, why this happens?
The reason is at the end of the log: binary /sbin/syslog-ng is linked against libraries in /usr or /opt libevtlog.so.0 => /usr/lib/libevtlog.so.0 (0xb77a1000) libpcre.so.0 => /usr/lib/libpcre.so.0 (0xb7754000) This is also a no-go in factory. The libs have to go to /lib too or if not possible, you can't enable them. There is a libevtlog package in $OBS/Base:System/libevtlog that installs into /%{_lib} -- please link against this package. You just need to link it into your branch project: osc linkpac Base:System libevtlog home:czanik:branches:Base:System libevtlog Further, you have either to link pcre statically, not link it at all or request a move of the lib to /%{_lib}. Gruesse / Regards, Marius Tomaschewski <mt@suse.de> <mt@novell.com> -- Server Technologies Team, SUSE LINUX Products GmbH, Nuernberg; GF: Markus Rex; HRB 16746 (AG Nuernberg) GPG/PGP public key fingerprint: DF17 271A AD15 006A 5BB9 6C96 CA2F F3F7 373A 1CC0 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 05/08/10 15:43, Marius Tomaschewski escribió:
Further, you have either to link pcre statically.
Nope, that isnt going to work, on purpose ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On 08/05/2010 09:43 PM, Marius Tomaschewski wrote:
Further, you have either to link pcre statically, not link it at all or request a move of the lib to /%{_lib}.
For an existing product it would be quite difficult. So for SLES I would disable pcre (AFAIK, not many people use it anyway). How can ifdef pcre out for SLES in the spec file? Bye, CzP -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Samstag, 7. August 2010 15:37:20 schrieb Peter Czanik:
Hello, Hello!
On 08/05/2010 09:43 PM, Marius Tomaschewski wrote:
Further, you have either to link pcre statically, not link it at all or request a move of the lib to /%{_lib}.
For an existing product it would be quite difficult. So for SLES I would disable pcre (AFAIK, not many people use it anyway). How can ifdef pcre out for SLES in the spec file?
%if 0%{?sles_version} <= 11 # for all released sles versions # --disable-pcre ... %endif sles_version is defined to 9, 10 or 11. similar with suse_version, except that it makes use of a 4-digit coded version numbers: %if 0%{?suse_version} <= 1130 # for released opensuse versions # --disable-pcre ... %endif See also: http://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto Gruesse / Regards, Marius Tomaschewski <mt@suse.de> <mt@novell.com> -- Server Technologies Team, SUSE LINUX Products GmbH, Nuernberg; GF: Markus Rex; HRB 16746 (AG Nuernberg) GPG/PGP public key fingerprint: DF17 271A AD15 006A 5BB9 6C96 CA2F F3F7 373A 1CC0 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 2010-08-09 11:51:44 +0200, Marius Tomaschewski wrote:
%if 0%{?sles_version} <= 11 # for all released sles versions # --disable-pcre ... %endif
sles_version is defined to 9, 10 or 11. similar with suse_version, except that it makes use of a 4-digit coded version numbers:
%if 0%{?suse_version} <= 1130 # for released opensuse versions # --disable-pcre ... %endif
only the if suse_version is needed. it will work on the sles versions aswell. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 05 August 2010 21:23:42 Peter Czanik wrote:
Hello,
Syslog-ng 3.1.2 was released yesterday, so I started to prepare a version update, as it will make almost all patches redundant. I did a bco, updated syslog-ng, checked in, and found, that it compiles fine on all openSUSE versions, but fails to compile on SLES 11 SP1.
Actually, it compiles, but the checks fail, for details check https://build.opensuse.org/package/live_build_log?arch=i586&package=sysl og-ng&project=home%3Aczanik%3Abranches%3ABase%3ASystem&repository=SLE_11 _SP1
Two questions:
1.) does it need to be able to build sles11 packages, or it is not a requirement to be able to sr it to factory?
It's not a requirement for a submitrequest to Factory.
2.) could anyone with access to SLES 11 SP1 check, why this happens? error is:
binary /sbin/syslog-ng is linked against libraries in /usr or /opt libevtlog.so.0 => /usr/lib/libevtlog.so.0 (0xb77a1000) libpcre.so.0 => /usr/lib/libpcre.so.0 (0xb7754000) so, it seems that these are new requirements. On my 11.3 system libpcre.so.0 is in /lib and not anymore in /usr/lib - so that explains why it works on 11.3. To fix this, you would need to either disable the dependency on these two libs for SLE11 or fix the libraries to live /lib. Moving the libs is not feasible right now IMO - so my recommendation would be to submit to Factory - unless you can disable the libs on just SLE11 builds! Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
El 05/08/10 15:23, Peter Czanik escribió:
1.) does it need to be able to build sles11 packages, or it is not a requirement to be able to sr it to factory?
Factory and SLE 11 are different products, and while it is desirable to get it running on it, the only requirement is getting it running in Factory.
2.) could anyone with access to SLES 11 SP1 check, why this happens?
This happends due to an "unfortunate" (read crazy) requirement: we have to support /usr in a remote system. so all stuff that gets installed in /bin /sbin must not be linked to stuff in /usr as it may not be available. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 2010-08-05 at 20:03 -0400, Cristian Rodríguez wrote:
El 05/08/10 15:23, Peter Czanik escribió:
1.) does it need to be able to build sles11 packages, or it is not a requirement to be able to sr it to factory?
Factory and SLE 11 are different products, and while it is desirable to get it running on it, the only requirement is getting it running in Factory.
2.) could anyone with access to SLES 11 SP1 check, why this happens?
This happends due to an "unfortunate" (read crazy) requirement: we have to support /usr in a remote system. so all stuff that gets installed in /bin /sbin must not be linked to stuff in /usr as it may not be available.
Which breaks many many things. People just don't really care about these issues, and I wouldn't call that 'supported' in any sense. It's more like: 'it works if you are lucky'. I think that /usr on nfs, or even on a different disk should just get a reality check, and be finally dropped. People who want it, should really look into making 'read-only /' work, instead of jumping through all these hoops with /usr -- trying something that will never really work. :) Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 05/08/10 21:03, Kay Sievers escribió:
It's more like: 'it works if you are lucky'.
Thought I have never tested it, I assume it may work according to the output of pom(6) ;-)
I think that /usr on nfs, or even on a different disk should just get a reality check, and be finally dropped. People who want it, should really look into making 'read-only /'
Mounting /var/tmp , /var/run and /tmp in tmpfs ..and so on.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 06 Aug 2010 03:03:22 +0200 Kay Sievers <kay.sievers@suse.de> wrote:
I think that /usr on nfs, or even on a different disk should just get a reality check, and be finally dropped.
Having /usr, /var, /opt and /tmp on different partitions / disks is basically a standard setup for lots of real-world corporate installations. The people who break such standard setups (or even think about breaking them) all the time should just get a reality check... (and finally try to find out, how their stuff is used in the real world outside of their own laptop) -- Stefan Seyfried "Theory and practice sometimes clash. And when that happens, theory loses. Every single time." -- Linus Torvalds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 2010-08-06 at 09:42 +0200, Stefan Seyfried wrote:
On Fri, 06 Aug 2010 03:03:22 +0200 Kay Sievers <kay.sievers@suse.de> wrote:
I think that /usr on nfs, or even on a different disk should just get a reality check, and be finally dropped.
Having /usr, /var, /opt and /tmp on different partitions / disks is basically a standard setup for lots of real-world corporate installations.
The people who break such standard setups (or even think about breaking them) all the time should just get a reality check...
/usr not on the rootfs is broken since ages for anything that isn't a simple server. It does not make any sense to do that, and that's why nobody really cares. Many things plugging into udev/hotplug break if /usr is not available at early boot. I stopped asking people to fix such things. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Kay Sievers <kay.sievers@suse.de> [2010-08-06 13:36]:
On Fri, 2010-08-06 at 09:42 +0200, Stefan Seyfried wrote:
On Fri, 06 Aug 2010 03:03:22 +0200 Kay Sievers <kay.sievers@suse.de> wrote:
I think that /usr on nfs, or even on a different disk should just get a reality check, and be finally dropped.
Having /usr, /var, /opt and /tmp on different partitions / disks is basically a standard setup for lots of real-world corporate installations.
The people who break such standard setups (or even think about breaking them) all the time should just get a reality check...
/usr not on the rootfs is broken since ages for anything that isn't a simple server. It does not make any sense to do that, and that's why nobody really cares.
Many things plugging into udev/hotplug break if /usr is not available at early boot. I stopped asking people to fix such things.
Unfortunately an all too common attitude in Linuxland. Anyway, can we then just be honest and officially abandon the now arbitrary /bin /sbin -- /usr/bin /usr/sbin separation by moving stuff and symlinking /bin and /sbin to /usr? It's nothing uncommon, Solaris/OpenSolaris, HP-UX, and AIX for example all don't have a separate /bin any more. It would certainly ease the pain with linking libraries which are in /usr. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-06 15:27, Guido Berhoerster wrote:
* Kay Sievers <kay.sievers@suse.de> [2010-08-06 13:36]:
sr not on the rootfs is broken since ages for anything that isn't a simple server. It does not make any sense to do that, and that's why nobody really cares.
Many things plugging into udev/hotplug break if /usr is not available at early boot. I stopped asking people to fix such things.
Unfortunately an all too common attitude in Linuxland. Anyway, can we then just be honest and officially abandon the now arbitrary /bin /sbin -- /usr/bin /usr/sbin separation by moving stuff and symlinking /bin and /sbin to /usr? It's nothing uncommon, Solaris/OpenSolaris, HP-UX, and AIX for example all don't have a separate /bin any more. It would certainly ease the pain with linking libraries which are in /usr.
That would be the appropriate move, of course. If a separate /usr partition is no longer supported, its better if /usr is removed completely, in order to avoid confusions. And of course, the documentation has to be changed. For example, chapter IV.20, The Directory Structure /usr /usr has nothing to do with users, but is the acronym for UNIX system resources. The data in /usr is static, read-only data that can be shared among various hosts compliant with the Filesystem Hierarchy Standard (FHS). This directory contains all application programs and establishes a secondary hierarchy in the file system. KDE4 and GNOME are also located here. /usr holds a number of subdirectories, such as /usr/bin, /usr/sbin, /usr/local, and /usr/share/doc. But now, if it can't go to a separate partition, it can no longer be shared. Wrong documentation. Bugzilla? What about the FHS? Does it has to be changed? Do we adhere to it or not? - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxcFFAACgkQU92UU+smfQVZ1ACeKP5sx8uOF/GfmZAHPqXDgVCc oewAoIYJ5VgQEWvZ+sSqw9dBNb2q+BV+ =YrcM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 08/06/2010 at 3:55 PM, "Carlos E. R." <carlos.e.r@opensuse.org> wrote: That would be the appropriate move, of course. If a separate /usr partition is no longer supported, its better if /usr is removed completely, in order to avoid confusions.
And of course, the documentation has to be changed. For example, chapter IV.20,
The Directory Structure
/usr
/usr has nothing to do with users, but is the acronym for UNIX system resources. The data in /usr is static, read-only data that can be shared among various hosts compliant with the Filesystem Hierarchy Standard (FHS). This directory contains all application programs and establishes a secondary hierarchy in the file system. KDE4 and GNOME are also located here. /usr holds a number of subdirectories, such as /usr/bin, /usr/sbin, /usr/local, and /usr/share/doc.
It could only be propely shared between computers of the same arch anyhow... On my system most binaries in there are elf64, which would certainly not run on other computers here... so sharing using NFS would be impossible anyway (this is ok for /usr/lib, as there we split /usr/lib64 again). Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-06 18:11, Dominique Leuenberger wrote:
On 08/06/2010 at 3:55 PM, "Carlos E. R." <carlos.e.r@opensuse.org> wrote: That would be the appropriate move, of course. If a separate /usr partition is no longer supported, its better if /usr is removed completely, in order to avoid confusions.
And of course, the documentation has to be changed. For example, chapter IV.20,
The Directory Structure
/usr
/usr has nothing to do with users, but is the acronym for UNIX system resources. The data in /usr is static, read-only data that can be shared among various hosts compliant with the Filesystem Hierarchy Standard (FHS). This directory contains all application programs and establishes a secondary hierarchy in the file system. KDE4 and GNOME are also located here. /usr holds a number of subdirectories, such as /usr/bin, /usr/sbin, /usr/local, and /usr/share/doc.
It could only be propely shared between computers of the same arch anyhow... On my system most binaries in there are elf64, which would certainly not run on other computers here... so sharing using NFS would be impossible anyway (this is ok for /usr/lib, as there we split /usr/lib64 again).
No longer, as they say that it is no longer supported and that they don't solve bugzillas about that. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Elessar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxcW3sACgkQU92UU+smfQWzAgCfQyX044Wvm9DcrcM0h0PGK8+8 wNMAnjiJgOYbIYI7+dvyT0hiKIHjH/Og =QTOL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/06/2010 12:11 PM, Dominique Leuenberger wrote:
On 08/06/2010 at 3:55 PM, "Carlos E. R." <carlos.e.r@opensuse.org> wrote: That would be the appropriate move, of course. If a separate /usr partition is no longer supported, its better if /usr is removed completely, in order to avoid confusions.
And of course, the documentation has to be changed. For example, chapter IV.20,
The Directory Structure
/usr
/usr has nothing to do with users, but is the acronym for UNIX system resources. The data in /usr is static, read-only data that can be shared among various hosts compliant with the Filesystem Hierarchy Standard (FHS). This directory contains all application programs and establishes a secondary hierarchy in the file system. KDE4 and GNOME are also located here. /usr holds a number of subdirectories, such as /usr/bin, /usr/sbin, /usr/local, and /usr/share/doc.
It could only be propely shared between computers of the same arch anyhow... On my system most binaries in there are elf64, which would certainly not run on other computers here... so sharing using NFS would be impossible anyway (this is ok for /usr/lib, as there we split /usr/lib64 again).
I don't really get this argument. Why wouldn't you have 32- and 64-bit /usr's that get exported to the different arches? - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxcW+EACgkQLPWxlyuTD7KhMACeLlna6gVqnm7WHjxcEIfXa8Hx KU4An2crOUuWFfo84+lIgEMQBgllWRKO =VVZ6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 2010-08-06 at 15:27 +0200, Guido Berhoerster wrote:
* Kay Sievers <kay.sievers@suse.de> [2010-08-06 13:36]:
On Fri, 2010-08-06 at 09:42 +0200, Stefan Seyfried wrote:
On Fri, 06 Aug 2010 03:03:22 +0200 Kay Sievers <kay.sievers@suse.de> wrote:
I think that /usr on nfs, or even on a different disk should just get a reality check, and be finally dropped.
Having /usr, /var, /opt and /tmp on different partitions / disks is basically a standard setup for lots of real-world corporate installations.
The people who break such standard setups (or even think about breaking them) all the time should just get a reality check...
/usr not on the rootfs is broken since ages for anything that isn't a simple server. It does not make any sense to do that, and that's why nobody really cares.
Many things plugging into udev/hotplug break if /usr is not available at early boot. I stopped asking people to fix such things.
Unfortunately an all too common attitude in Linuxland. Anyway, can we then just be honest and officially abandon the now arbitrary /bin /sbin -- /usr/bin /usr/sbin separation by moving stuff and symlinking /bin and /sbin to /usr? It's nothing uncommon, Solaris/OpenSolaris, HP-UX, and AIX for example all don't have a separate /bin any more. It would certainly ease the pain with linking libraries which are in /usr.
Anything like this sounds good to me. It's just a pretty useless exercise with this artificial split. I would understand to have 'the desktop' split out into /usr, but everything else is just crazy. An it seems entirely random what we do here today. The 'maybe needed at boot' thing just does not mean anything today. The real fix is a properly working read-only /, for people who use /usr on a separate filesystem, anyway. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/06/2010 10:00 AM, Kay Sievers wrote:
On Fri, 2010-08-06 at 15:27 +0200, Guido Berhoerster wrote:
* Kay Sievers <kay.sievers@suse.de> [2010-08-06 13:36]:
On Fri, 2010-08-06 at 09:42 +0200, Stefan Seyfried wrote:
On Fri, 06 Aug 2010 03:03:22 +0200 Kay Sievers <kay.sievers@suse.de> wrote:
I think that /usr on nfs, or even on a different disk should just get a reality check, and be finally dropped.
Having /usr, /var, /opt and /tmp on different partitions / disks is basically a standard setup for lots of real-world corporate installations.
The people who break such standard setups (or even think about breaking them) all the time should just get a reality check...
/usr not on the rootfs is broken since ages for anything that isn't a simple server. It does not make any sense to do that, and that's why nobody really cares.
Many things plugging into udev/hotplug break if /usr is not available at early boot. I stopped asking people to fix such things.
Unfortunately an all too common attitude in Linuxland. Anyway, can we then just be honest and officially abandon the now arbitrary /bin /sbin -- /usr/bin /usr/sbin separation by moving stuff and symlinking /bin and /sbin to /usr? It's nothing uncommon, Solaris/OpenSolaris, HP-UX, and AIX for example all don't have a separate /bin any more. It would certainly ease the pain with linking libraries which are in /usr.
Anything like this sounds good to me. It's just a pretty useless exercise with this artificial split. I would understand to have 'the desktop' split out into /usr, but everything else is just crazy. An it seems entirely random what we do here today. The 'maybe needed at boot' thing just does not mean anything today.
What devices need access to /usr? Can those events be cached and reissued if the binary serving them isn't available?
The real fix is a properly working read-only /, for people who use /usr on a separate filesystem, anyway.
That would make a lot of things go but is unfortunately pretty complicated. A shared /usr is a good first step that just happens to also be pretty low-hanging fruit. While this feature used to be just about serving /usr to workstations with very small (or nonexistent) disks, all those old arguments are coming back in the form of optimizing storage for virtual machines. Sure, there's not a whole lot of benefit for desktop or SOHO users, but the storage benefits when you have a lot of VMs sharing the same /usr are substantial. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxcSL4ACgkQLPWxlyuTD7K9RACgmD4pZvxppL/IFwM58fgZPcvk aM0An2HH1IXt+S3TqhWqM/B/T7ri9ufV =fYJw -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-06 19:39, Jeff Mahoney wrote:
On 08/06/2010 10:00 AM, Kay Sievers wrote:
The real fix is a properly working read-only /, for people who use /usr on a separate filesystem, anyway.
That would make a lot of things go but is unfortunately pretty complicated. A shared /usr is a good first step that just happens to also be pretty low-hanging fruit.
While this feature used to be just about serving /usr to workstations with very small (or nonexistent) disks, all those old arguments are coming back in the form of optimizing storage for virtual machines.
Sure, there's not a whole lot of benefit for desktop or SOHO users, but the storage benefits when you have a lot of VMs sharing the same /usr are substantial.
Ok, then, do we start filling bugzillas about /usr on a separate partition, or not? The answer from your coworker Kay seems to indicate "no". - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Elessar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxcXM8ACgkQU92UU+smfQV9cQCcD2gA82S0zTBjhjOZm6Y8NVbh f94AnjIEQjYvpgN66GGmNl9Y3ChUzxpi =fbpu -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 06/08/10 15:04, Carlos E. R. escribió:
The answer from your coworker Kay seems to indicate "no".
It is up to the specific package mainteiner to fix the issue or not. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/06/2010 03:04 PM, Carlos E. R. wrote:
On 2010-08-06 19:39, Jeff Mahoney wrote:
On 08/06/2010 10:00 AM, Kay Sievers wrote:
The real fix is a properly working read-only /, for people who use /usr on a separate filesystem, anyway.
That would make a lot of things go but is unfortunately pretty complicated. A shared /usr is a good first step that just happens to also be pretty low-hanging fruit.
While this feature used to be just about serving /usr to workstations with very small (or nonexistent) disks, all those old arguments are coming back in the form of optimizing storage for virtual machines.
Sure, there's not a whole lot of benefit for desktop or SOHO users, but the storage benefits when you have a lot of VMs sharing the same /usr are substantial.
Ok, then, do we start filling bugzillas about /usr on a separate partition, or not?
The answer from your coworker Kay seems to indicate "no".
I don't think it's an easy yes or no answer and neither Kay or I speak on behalf of the entire openSUSE community. The discussion on whether or not this is a feature we want to maintain is just warming up, I think. Kay is focused mainly on the small desktop and portable systems - neither of which would have any use for a feature like this, so I can see where his point comes from. All of my systems are set up with 4 volumes: root, boot, swap, and home. But then I'm not running anything virtualized. I've seen a number of requests and discussions around optimizing storage for virtualization and they only seem to be heating up. I'd love to see openSUSE be able to function as a single-system-image cluster (which requires a shared root), but that's just a personal interest of mine. A read-only root has essentially the same requirements. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxcZZAACgkQLPWxlyuTD7K1bQCfc82qGU7VX31rwtEz4SK0gJcj 4TAAmgJrWi1+1fEzwMF3Lbh4Kh5nrHzB =sbkh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Jeff Mahoney wrote:
Kay is focused mainly on the small desktop and portable systems - neither of which would have any use for a feature like this, so I can see where his point comes from. All of my systems are set up with 4 volumes: root, boot, swap, and home. But then I'm not running anything virtualized.
Pretty much the same setup here, although I have mostly stopped using a separate boot partition.
I've seen a number of requests and discussions around optimizing storage for virtualization and they only seem to be heating up. I'd love to see openSUSE be able to function as a single-system-image cluster (which requires a shared root), but that's just a personal interest of mine. A read-only root has essentially the same requirements.
A couple of years back, I ran a smallish cluster with SuSE Linux (7 or 8) as an SSI. Took a lot of fiddling, IIRC. /Per Jessen, Zurich -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-07 15:48, Per Jessen wrote:
Jeff Mahoney wrote:
Kay is focused mainly on the small desktop and portable systems - neither of which would have any use for a feature like this, so I can see where his point comes from. All of my systems are set up with 4 volumes: root, boot, swap, and home. But then I'm not running anything virtualized.
Pretty much the same setup here, although I have mostly stopped using a separate boot partition.
You may have to reconsider for 11.3 Several people are reporting problems when the root partition is beyond the 128 GiB limit. Yast warns of possible problems, and the system is unbootable. However, in the same machine and partition, 11.2 worked fine. There are two solutions: grub2 (manually or with an ubuntu small "sacrificial" small root), or a small /boot - again. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxf67cACgkQU92UU+smfQWlCwCfdfRFJXtihigl8i01PNqPy8NF AzQAn2DRKZJ0dIX0v7LpzR5YkNyH/K3U =Jq6i -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-06 02:03, Cristian Rodríguez wrote:
El 05/08/10 15:23, Peter Czanik escribió:
1.) does it need to be able to build sles11 packages, or it is not a requirement to be able to sr it to factory?
Factory and SLE 11 are different products, and while it is desirable to get it running on it, the only requirement is getting it running in Factory.
2.) could anyone with access to SLES 11 SP1 check, why this happens?
This happends due to an "unfortunate" (read crazy) requirement: we have to support /usr in a remote system. so all stuff that gets installed in /bin /sbin must not be linked to stuff in /usr as it may not be available.
For example, joe does not work. Which means that joe does not work in rescue mode when a partition failed to mount, which means using vi (which also complains about some missing part). Now you say: learn vi. Ok, I know some vi; just you try to use vi in a Spanish keyboard with a running default, ie, US, keyboard, Where is the colon ":". And the exclamation mark "!"? All this because a small error in fstab that you have to correct to boot. Now, why use /usr at all. Me, because it supposed to work, and because it is a method to add space to a filesystem. It is quite typical on some installations to have everything on its own partition. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxb00EACgkQU92UU+smfQUURQCfYAFfBHpbjbqlf7hL8o+CD3Bs QvwAoJO3YSZdzWsh+GUrtwzi5RRUghmR =R2eg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/05/2010 08:03 PM, Cristian Rodríguez wrote:
El 05/08/10 15:23, Peter Czanik escribió:
1.) does it need to be able to build sles11 packages, or it is not a requirement to be able to sr it to factory?
Factory and SLE 11 are different products, and while it is desirable to get it running on it, the only requirement is getting it running in Factory.
2.) could anyone with access to SLES 11 SP1 check, why this happens?
This happends due to an "unfortunate" (read crazy) requirement: we have to support /usr in a remote system. so all stuff that gets installed in /bin /sbin must not be linked to stuff in /usr as it may not be available.
The meaning of "remote" in this context is changing. I mentioned this in another post, but remote could be the guest-host link where the number of guests is many. We're seeing a lot of demand for optimizing storage requirements when a lot of virtual machines are running essentially the same software but are all keeping separate copies of it. When these are on clustered storage and accessed by multiple hosts the duplication between VM images is huge. Kay mentioned that having a sharable root is the right solution - and he's right - but that is a *whole* lot more involved than allowing just /usr to be separate. That's a good final goal but not an argument against keeping a separate /usr. A separate /usr is a step along the path to that goal. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxcSuAACgkQLPWxlyuTD7KD7gCeLYADe1Bq6TZdYNydKWfbCFLQ na8AniGC1knlv9Z2NLz/aWIEN9hmeFdp =jkCv -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (14)
-
Andreas Jaeger -
Carlos E. R. -
Carlos E. R. -
Carlos E. R. -
Cristian Rodríguez -
Dominique Leuenberger -
Guido Berhoerster -
Jeff Mahoney -
Kay Sievers -
Marcus Rueckert -
Marius Tomaschewski -
Per Jessen -
Peter Czanik -
Stefan Seyfried