Hi, Thanks to Jean for the clarification of opkgc. 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? 2. OPD, Selector, Configurator, and PackageInUn need to be adjusted to the new opkgs? 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? 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? 4. Will not CLI be affected? Regards, - DongInn 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> > ------------------------------------------------------------------------- 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
