On 10/27/06, Les Howell <hlhowell@pacbell.net> wrote:
The R package is for local installation on a client that contains a hard disk. The U version is for "diskless clients", where the system software resides on a file server, say for a college class room for example, which would save the cost of the disks and centralize software control and updates.
Regards, Les H
OK, but how to devide the package say, FireFox or GIMP into such two packages? what must go to first "U" and what to second "R" ? --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
The R package is for local installation on a client that contains a hard disk. The U version is for "diskless clients", where the system software resides on a file server, say for a college class room for example, which would save the cost of the disks and centralize software control and updates.
Regards, Les H
"R" package: /etc. Stuff that may be different between two machines. "U" package (originally stands for /usr, which was commonly shared back in 5.3): binaries, libraries, help texts, docs, samples, etc. everything that's static.
OK, but how to devide the package say, FireFox or GIMP into such two packages? what must go to first "U" and what to second "R" ?
That's easy. From the output of `rpm -ql gimp`, put all files from /etc into r, all the others into u. Let's take a more complicated example, e.g. sendmail: r /etc u /sbin/conf.d u /usr/bin u /usr/lib u /usr/sbin u /usr/share r /var/adm r /var/lib/sendmail r /var/run/sendmail r /var/spool Of course all this R and U packaging requires that the version of the R package matches (1) the version of the U package on the local system and (2) the version of the U package in /tftpboot. This is usually no problem. -`J' -- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Of course all this R and U packaging requires that the version of the R package matches (1) the version of the U package on the local system and (2) the version of the U package in /tftpboot. This is usually no problem. ...
So in essence, it is: # rpm --root / -q foobar-r foobar-u /etc/fluff /usr/fluff # rpm --root /tftpboot/linux -q foobar-r foobar-u /etc/fluff foobar-u not installed and the netboot client mounts certain directories (such as /usr and /opt) over nfs. Or in case you need to make local modifications, bind mount /usr to /tftpboot/linux/usr while chrooted. This is an advantage over installing foobar-u in /tftpboot/linux too. It saves space. -`J' -- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
ok, so on clients without Hard Disk: you must download both U & R packages (on each boot) right? on clients with Hard Disk: you must download only R packages right (on each boot), and U are preinstalled (one time) ? Is this correct? What do others think of this idea? --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 28 October 2006 05:36, Alexey Eremenko wrote:
ok, so on clients without Hard Disk: you must download both U & R packages (on each boot) right?
on clients with Hard Disk: you must download only R packages right (on each boot), and U are preinstalled (one time) ? Is this correct?
Majority is installing all on one machine anyway. It will be more work for maintainers as it will double number of packages and introduce few thousands opportunities to forget something when updating package. Not to forget huge pile of existing packages that have to be changed, tested to make sure that they all work. The /etc and preinstalled /var are not that big and savings will be minor comparing to effort. -- Regards, Rajko M. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Majority is installing all on one machine anyway. It will be more work for maintainers as it will double number of packages
Not the number of .src.rpm packages.
and introduce few thousands opportunities to forget something when updating package.
You _do_ use a package manager, don't you?
Not to forget huge pile of existing packages that have to be changed,
I did not say everything has to be changed immediately. I think if this was done to the biggest packages first there would be enough gain.
tested to make sure that they all work.
The /etc and preinstalled /var are not that big and savings will be minor comparing to effort.
The idea is that I would not need to install kde3U (/opt/kde3=250 MB, YMMV) and OpenOfficeU (most likely just as much) on every client and instead devote that space to something else. -`J' -- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 28 October 2006 08:20, Jan Engelhardt wrote:
Majority is installing all on one machine anyway. It will be more work for maintainers as it will double number of packages
Not the number of .src.rpm packages.
What is the benefit that src.rpm number is not grown? You have to double number of installable packages.
and introduce few thousands opportunities to forget something when updating package.
You _do_ use a package manager, don't you?
Not to forget huge pile of existing packages that have to be changed,
I did not say everything has to be changed immediately. I think if this was done to the biggest packages first there would be enough gain. Folk at SUSE already politely explained that adding binaries for i686 will be too much for maintenance and distribution, in some previous thread. I don't
I talk about more spots that one can forget to update during package creation, not on the user side ie. installation, but yes, it can be automated once packages are reconfigured. It will require changes in package management client software too. think they will see splitting packages as smaller burden.
tested to make sure that they all work.
The /etc and preinstalled /var are not that big and savings will be minor comparing to effort.
The idea is that I would not need to install kde3U (/opt/kde3=250 MB, YMMV) and OpenOfficeU (most likely just as much) on every client and instead devote that space to something else.
-`J'
Maybe I see different scenario than you, but I don't see any problem to use NFS to export /usr, /opt to multiple clients. I don't use this configuration so I don't know how that would work in a practice, but if multiple users can use one /usr and one /opt in common, single machine configuration it should work with distributed clients too. The installation time problem where installer program will try to install all on one machine is probably easier to solve with classic means, like installing and configuring hardware, than removing all that you don't need after installation, or if you have more machines of the same kind, install on one and than make plain copies to others, etc. If you have something like 32 and 64 mix in the network, than you can have 2 servers, or single one with two sets of unchangeable directories. Remain directories that are not really big can be kept locally. Am I missing something? -- Regards, Rajko M. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Jan Engelhardt wrote
The /etc and preinstalled /var are not that big and savings will be minor comparing to effort.
The idea is that I would not need to install kde3U (/opt/kde3=250 MB, YMMV) and OpenOfficeU (most likely just as much) on every client and instead devote that space to something else.
I can't resist to remark that you don't have these problems on diskless clients who mount / from the server and use a link mechanism for client-dependent files in /etc to /etc/local. You don't install any RPM on the client in such a case, and (if you don't need /tmp and swap on a local hard disk) clients can even work completely without a harddisk. We've been successfully deploying that concept for years now. But I remember you judging that concept as "Bah." :-) Anyway, why can't you reach the effect with your unionfs when you hold the client-dependent files on special /etc for your client? Why do you want to install RPMs on the diskless clients? Packages like gimp don't need any different files in /etc/ for two clients, and so do 99% of all packages in SuSE. So I really don't see the need for such R-rpms... cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
ok, so on clients without Hard Disk:
it does not matter with or without. In case clients have a harddisk, the R packages are installed, and U is sourced via NFS, and if they do not have a harddisk, the R packages are installed _anyhow_ (however, on the _server_) and both R and U are nfs-mounted.
you must download both U & R packages (on each boot) right?
on clients with Hard Disk: you must download only R packages right (on each boot), and U are preinstalled (one time) ? Is this correct?
What do others think of this idea? --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-`J' -- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2006-10-28 at 15:17 +0200, Jan Engelhardt wrote:
ok, so on clients without Hard Disk:
it does not matter with or without. In case clients have a harddisk, the R packages are installed, and U is sourced via NFS, and if they do not have a harddisk, the R packages are installed _anyhow_ (however, on the _server_) and both R and U are nfs-mounted.
you must download both U & R packages (on each boot) right?
on clients with Hard Disk: you must download only R packages right (on each boot), and U are preinstalled (one time) ? Is this correct?
What do others think of this idea?
With the size and price of today's hard-drives I see no advantage in splitting any packages. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
With the size and price of today's hard-drives I see no advantage in splitting any packages.
Not everyone has a fat 250G drive, esp. educational institutions have older boxes in service. -`J' -- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, Oct 29, 2006 at 12:58:45AM +0200, Jan Engelhardt wrote:
With the size and price of today's hard-drives I see no advantage in splitting any packages.
Not everyone has a fat 250G drive, esp. educational institutions have older boxes in service.
That's right but I'd strongly recommend not to implement such a mechanism by messing up each and every package by manually splitting them into subpackages that have a distinction only in a pure technical reason rather than a semantical one. I'd recommend instead to enhance the package manager with a mechanism to configure it filtering away files based on a pattern that can be configured for a specific instance. That way you can use this feature with each and every package without requiring the packager to consider this on creation of the package. We use a similar technology (although not with RPM) in a heterogeneous cluster environment to share common files between different architectures without duplicating them for each and every platform and without manually marking these files/packages as being noarch packages. That way you can also omit creation of something messy things like these *-32bit packages on biarch systems. Instead you just install the x86 and x86_64 package on a x86_64 system and the intelligence in the package manager makes sure that a) you have both library versions installed, b) always get the x86_64 binary when calling a binary (unless specified otherwise), and c) shared files are present on the system only once. Actually the technology is more generic so that you can install for instance x86_64, x86, Sparc, and Alpha packages on a shared volume and the package mapper automatically creates a view to this single volume to make each system seeing only the files of relevance for their architecture. There is another advantage of the very same technology: With some more rule patterns it allows installation of multiple versions of a package allowing the system to see all (incompatible) versions of a library but only one version of the development headers. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
On Sun, Oct 29, 2006 at 01:29:24AM +0200, Robert Schiele wrote:
I'd recommend instead to enhance the package manager with a mechanism to configure it filtering away files based on a pattern that can be configured for a specific instance. That way you can use this feature with each and every package without requiring the packager to consider this on creation of the package.
Rpm has actually already support for excluding directories, the macro for this is %{_netsharedpath}. Cheers, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (7)
-
Alexey Eremenko -
Frank Steiner -
Jan Engelhardt -
Kenneth Schneider -
Michael Schroeder -
Rajko M -
Robert Schiele