On Tue, 10 Apr 2001, Chris Petro wrote:
> 
>       Go back and re-read what I wrote. That doesn't do it. 
> 
>       Using the comps file allows you to choose *different* packages for install,
>       but must be specified in the ks.config file. What I am going to acheive
>       is the ability to install different versions as well as different 
>       packages from the same "repository".
> 
>       This simplifies *many* things, at the cost of some complexity in 
>       the software. 
> 
>       It eliminates dinking around with DHCP configuration files to point to
>       different ks.config files. It eliminates having to propigate and 
>       syncronize new RPMs across multiple repositories, it provides the 
>       ability to change control the configuration files so you can roll
>       back to a previous version of the installation set etc. 

i'm always interested in new ways to approach kickstart, since it's became
one of my favourite nightmares since 5.2 :)
but, maybe i'm missing something from this thread and it is possible that
i missunderstand something here..

q1: how would you tell kickstart which profile you wanna install
today? edit file on floppy each time? explore system and determine what it
needs?

q2: not sure how this huge "repository" would be implemented, but if i'd
try to imagine it based on RH architecture, first problem you'd meet would
be - RH install craps out on two versions of the same package in RPMS. and
idealogically they shouldn't be there.. if we're talking about two
different versions.. should we be thinking about two different
distribution versions here?

> > >   How do I install one version of package <x> on one cluster, and version
> > >   <y> on another?
> > You have different distribution roots on different NFS server exports.
> > There may be less space consuming ways.  Maybe symlinks in the exported
> > directories that point to the pertinent RPM in another directory.  Just off
> > the top of my head.
> 
>       Not acceptable. Entirely too maintenance intensive. 

q3: where would you maintain your "profile" definitions/package versions
they need? you'd have to maintain config files of smth.

q4: what's your sollution right now? how do you maintain those 20 types.

thanks.



_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list

Reply via email to