Hi, Le Wednesday 30 May 2007 16:45:57 DongInn Kim, vous avez écrit : > Hi, > > Thanks to Jean for the clarification of opkgc.
You're welcome. > Yes, I understand what opkgc does but since it made the structure of > OSCAR packages changed a lot and one of the rpm based OSCAR package > management tools, PackageInUn, could not have been adjusted to the new > structure, I thought that opkgc may be able to [make it easy to] provide > a user friendly interface to handle the feature of PackageInUn as well > as the oscar-like compiler for the various linux based package manager > (e.g, rpm or deb). > > (Note, new opkgs == OSCAR packages with the new opkg structure) > Apparently, opkgc is not an OSCAR package management tool but a > compiler. Opkgc however is supposed to build OSCAR packages with the new > opkg structure and I believe that opkgc need many current OSCAR tools > managing opkgs to be fixed/adjusted to work with the new opkgs. > For example, OPD, Selector, Configurator, and PackageInUn would need to > change for the new opkgs. > > So, here are some questions. > 1. Can OSCAR fully ready to use the new opkgs until OSCAR 5.1? It must be. > 2. OPD, Selector, Configurator, and PackageInUn need to be adjusted to > the new opkgs? In a few words (therefore incomplete): - OPD must manage apt or yum repos list - Selector is an alias for "apt|yum search opkg-*" - Configurator stays the same. configurator.html files are provided with opkg-<name> package, and installed in /var/lib/oscar/packages/<name>/ - PackageInUn is an alias for "cexec apt|yum install <package>" > 2-1. If it is not all, which one needs to be fixed? > 2-2. Selector and Configurator would still be used? > 3. Node_Package_Status table does not need to be used? In a farer future than 5.1. But for the moment, I think we are not ready to drop this table. > 3-1. We don't care about the status of opkgs according to nodes? > > id | name > ----+----------------------------- > 1 | should_not_be_installed > 2 | should_be_installed > 3 | run-configurator > 4 | install-bin-pkgs > 5 | run-script-post-rpm-install > 6 | run-script-post-clients > 7 | run-script-post-install > 8 | finished > > > 3-2. If so, who will take care of these? opkgc or something else? Some of these status can be checked using apt or rpm. For those who do not exist in apt or rpm, I don't know. > 4. Will not CLI be affected? > I don't think so. As far as Selector, opd and PackageInUn can keep the same interface. > Regards, > > - DongInn Regards, Jean > > Jean Parpaillon wrote: > > Hi, > > > > Le Tuesday 29 May 2007 20:58:30 Kim, DongInn, vous avez écrit : > >> Hi, > >> > >> I am wondering if we are dropping the User Friendly interface(GUI) for > >> implementing "Package Install/Uninstall" (in short, PackageInUn) feature > >> at oscar_wizard when opkgc is fully imported to the oscar installation. > >> http://oscar.openclustergroup.org/comp_opkgc > >> (FYI, we are not losing the feature of installing/uninstalling packages > >> and I believe that opkgc can take care of this.) > > > > Ok, let's clarify. > > opkgc is a *compiler*. It transforms an OSCAR package into a set of > > native packages (RPM or deb). That means that these packages, once > > compiled, are managed by native systems: apt, dpkg, rpm, yum, synaptic, > > my_favourite_rpm_tool, your_favourite_dpkg_manager, etc. Configuration at > > cluster level needs OSCAR stuff to be done, but concerning updating > > packages, removing them, or getting them from a repository it is done by > > native systems. That was the goal of opkgc. > > > > opkgc is not a user tool, as you don't run gcc when you want to run your > > executable. > > > > Furthermore, regarding any specification and documentation, it's included > > in opkgc tarball (wget > > http://oscar.gforge.inria.fr/downloads/opkgc-0.1.tar.gz && tar zxf opkgc* > > && cd opkgc && sudo make install) and I posted some slides which may help > > you understanding this. > > > >> PackageInUn was implemented in oscar_wizard (install/manage mode) until > >> oscar 4.2 and it has been one of OSCAR main functionalities that I like > >> to use to maintain my OSCAR cluster. > >> > >> But looks like that we have not planned to make any GUI to implement the > >> previous PackageInUn stuff on OSCAR 5.1 yet. > >> > >> The features that the previous PackageInUn can do are > >> 1. Add new package(s) to the existing cluster > >> 2. Remove/Uninstall some packages from the existing cluster > >> 3. Update oscarimage according to the addition or removal of the > >> packages. 4. Update the "Node_Package_Status" table in oda. > > > > oda is not concerned with package status anymore, AFAIK > > > >> 5. It was integrated with "Selector" (i.e., "Select OSCAR Packages..." > >> menu at oscar_wizard (manage mode)) > >> 6. GUI > >> > >> I do not really care about the GUI as long as opkgc (the new OSCAR > >> package management tool) can handle the obvious and inevitable issues > >> above but not all possibly. > >> > >> In addition, if we can not do this via opkgc until OSCAR5.1 or if it is > >> not worth to make the similar PackageInUn via opkgc, I think we need to > >> provide a full instruction/document of managing OSCAR packages in the > >> similar way that PackageInUn could have done it. > >> > >> What do you guys think about this? > > > > Once again, opkgc is not a packages manager. > > opd must be updated to handle new package format. I can do it right after > > I achieved repositories management but not now. > > So, if someone wants to do it, it consists of: > > - getting available OSCAR packages: > > yum|apt search opkg-* > > > > - installing packages: > > On server: > > yum|apt install opkg-<name> opkg-server-<name> > > On image: > > yum|apt install opkg-client-<name> > > Or on client: > > cexec [options] yum|apt install opkg-client-<name> > > Then run the appropriate scripts ('man opkg' once opkgc installed) > > > > - updating client: > > cexec yum|apt upgrade|update > > > > - removing package: > > On server: > > yum|apt remove opkg-<name> opkg-server-<name> > > On client: > > cexec yum|apt remove opkg-client-<name> -- ------------------------------------------------------------------------ Kerrighed inside - OSCAR outside http://kerrighed.org/ http://oscar.openclustergroup.org/ ------------------------------------------------------------------------ Jean PARPAILLON - Engineer - PARIS group - Office E210 IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France Tél: +33 2 99 84 22 33, Fax: +33 2 99 84 71 71 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
