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 spac
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
> ever
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 d
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
>
>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
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
>
>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
> 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-moun
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 cor
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?
>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/f
>> 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
On 10/28/06, Les Howell <[EMAIL PROTECTED]> wrote:
If you Firefox or Gimp would go into both, to provide the software on the
server for the U install disk, and on the system disk for the R version
standalone.
A diskless client actually has a disk, and will provide itself with swap
space on that (
On 10/27/06, Les Howell <[EMAIL PROTECTED]> 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 th
On 10/27/06, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
Hey,
in Solaris, many packages are split in two (e.g. SUNWzebrar and
SUNWzebrau, just to pick a random one), of which one (the 'u' one)
contains data that can be shared over NFS. This is an interesting
concept because it allows a smaller i
Hey,
in Solaris, many packages are split in two (e.g. SUNWzebrar and
SUNWzebrau, just to pick a random one), of which one (the 'u' one)
contains data that can be shared over NFS. This is an interesting
concept because it allows a smaller install image for diskless and
diskful clients and po
16 matches
Mail list logo
