I think Jeff and Jeremy are talking in orthogonal directions here... we
are currently using the base package for server RPMs and the rpmlists in
oscarsamples for clients. One of the main reasons for this was to allow
multiple package selections for certain distros, such as the regular and
'noX' lists for Mandrake. I think that the future probably lies in
treating the base package in a special way (probably in the same way
core packages are treated, since they are all going to be on all the
clients), and leaving those other package differences in other OSCAR
packages to add e.g. X to a client.
Jason
Jeremy Enos wrote:
At 10:01 AM 5/14/2004, Jeff Squyres wrote:
On Fri, 14 May 2004, Benoit des Ligneris wrote:
So the option I recommend would be to use the minimal image created
by the creation of an "empty" SIS image (i.e. : without providing
any RPM).
The oscarsample/*.rpmlist should be completely discarded and the
rpmlist should be provided by the chrooted (in the minimal image)
update-rpm should be used.
This might not be a bad thing.
But we'd still need *some* RPM list, right? Something for that
base/minimal set of RPMs to establish all the required dependencies
for that distro, right?
Also, is there a reason we're still using oscarsample/*.rpmlist
instead of packages/base/config.xml? I notice that the server RPMs
are in base/config.xml, but the client RPMs are still in
oscarsample/*.rpmlist.
There was a move to simplify things a long time ago by ditching the
oscarsample/*.rpmlist and using base/config.xml instead. It still
makes good sense, with one exception. In the new model, specific
package rpms aren't installed into the image, but after the fact... to
allow for heterogeneity. This means one of two things: either the
"base" package is special, and is used to build the image, or it's not
a package at all, and we continue with the *.rpmlist method. Either
way, we can't avoid special treatment.
I'm still leaning towards using a "base" package, and having it get
treated special. There are lots of advantages to packagizing it...
we have an infrastructure that will make use of it, it can make use of
infrastructure (filters, ODA, etc), and it's more easily updated or
substituted (even via OPD), etc. Image creation code will just have
to look specifically for it or something.
Jeremy
Was there a technical reason for that, or just hysterical raisins?
It maybe interesting, then, to create a "virtual" RPM for OSCAR that
would simply contain PreReqs (for instance an X windowing system,
etc.).
This virtual RPM will be distro and version dependant but can be
automatically generated from the information contain in the config.xml
that is directly avalaible in ODA.
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
