(original thread at the bottom of this message)
Hey,
I'm touching this thread again. Unfortunately I won't be at the call today but wanted to bring it up for discussion on the list in light of the empending freeze.
As best I recall there was lots of discussion about having versioning at the OPkg level as well as offering it at the RPM level (proposed here). We came to conclusion that we didn't have the XML support for OPkg (beyond OPD). We also had some issues with upgrade path and semantics about an 'oscar-release' RPM.
What I don't recall is if we came to an intermediate solution for the v4.1 release timeframe. Ideally I think what we want is an OPkg that has the release info at both the OPkg level and the RPM level. Then folks could have dependence on a given OPkg or RPM as they felt necessary. We sort of have that now with <requires> OPkg but not for a given version and we never finished the <requires><type>RPM</type>... XML support we'd talked of in the past.
So, what is reasonable in v4.1 to fulfull the request to have some mechanism for OPkg authors to have checks for their opkg to a given oscar version. Is it possible for this release or do we want to wait for v4.2, but outline what we need to have for it in v4.2.
Consider the ball rolling...
Thanks, --tjn
_________________________________________________________________________ Thomas Naughton [EMAIL PROTECTED] Research Associate (865) 576-4184
On Fri, 11 Feb 2005, Jeff Squyres wrote:
Moving to devel; we might as well have this discussion out in the open and solicit other opinions.
Hmm...
Still feels "dirty" to me. As I voiced on the teleconf, I am concerned about the failure scenario you mentioned at the end -- that we fail somewhere in the middle, but "rpm -qa oscar-release" would imply that everything was ok.
I guess I still don't understand why RPM should be the tool to enforce this kind of stuff -- it seems like the Wrong thing to do. Just because other projects do this does not mean that it is a Good Thing.
Note that I consider a Linux distro who uses this trick a different issue -- they install everything all at once, and if it succeeds, great. If it doesn't succeed, you have a totally hosed disk and one faulty/misleading RPM is the least of your problems; you'll likely end up re-installing from scratch anyway. Since OSCAR does not install everything at once, it breaks the fundamental assumption that you're getting version X. You may well not be at version X, or you may have been at version X at some time in the past -- but it doesn't imply anything about the current state of the system.
So the argument here about why this is a Good Thing is: an opkg will fail to install its RPMs if the oscar-release RPM version doesn't match. Right?
Specifically, the problem we're trying to solve here is finding a [range of] version[s] of OSCAR that an opkg's RPMs can work for, right?
Why use RPM for that? ("Why not?" is not a good enough answer) Seriously, what's the rationale for using RPM? Why does this make the job easier / better? (those are honest questions)
The argument in the mail below is that this oscar-release RPM will prevent confusing user situations where an OSCAR installation fails part way through. How would this sentinel RPM prevent such situations? As OSCAR currently stands, you'll still get an amorphous failure in the middle -- if you have an opkg that doesn't like the current oscar-release version, that RPM will fail to install because of failed dependencies (causing the wizard to fail). How is this simpler for users?
A second case: consider some opkgs that have RPMs that are dependent upon a specific version of OSCAR (x.y.z). Assumedly, that opkg's RPMS will require oscar-release==x.y.z. If you install oscar-release-x.y.z and then that opkg's RPMs, what about when you want to upgrade? The first thing the OSCAR wizard will try to do will be to "rpm -Uvh oscar-release-a.b.c" (assumedly where a.b.c > x.y.z), but that will fail because some RPM requires exactly vx.y.z. We don't have OSCAR upgrades yet, but we do want to have them someday.
Linux distros, for example, never upgrade this foo-release RPM except when upgrading the entire size *all at once* (as mentioned above), where such dependencies are resolved. So this is essentially a non-issue for them.
Unless we're going to get in the practice of cleaning up this kind of mess (i.e., uninstalling the offending RPMs first, then upgrading oscar-release, etc.), this isn't really workable. I dunno -- perhaps Pack/Dep can be used to figure this kind of stuff out, but it just seems like this causes a lot of extra work and is therefore the wrong tool to use, to me.
Why is it so hard to have in the config.xml what versions of OSCAR you're supposed to work with? And don't we already have that? As an added bonus, it's a whole lot easier to update a config.xml with a pre-existing RPM if you find new versions of OSCAR that your RPM works with.
I'm really not trying to be a jerk -- I honestly don't see the benefit of using a sentinel RPM, and I see potential problems down the road. Everything is not a nail. :-\
On Feb 11, 2005, at 11:24 AM, Thomas Naughton wrote:
Hello,
On this week's teleconf (2/7) I mentioned the 'oscar-release' RPM and we discussed a few semantic issues about what an opkg author could (and could not) assume.
SUMMARY: Basically the issue was, if you install the RPM and then things fail before OSCAR is fully installed a user could be confused. A suggestion was to create a "stage" file that would act as a 'high-water' mark for more precise inquiry as to the installation status; when OSCAR is fully installed the "stage" would be complete (or something like that).
This complicates matters and I think we can reduce this complexity by simply declaring a few simple "rules" to clarify what one can gleam from the existence of this 'oscar-release' RPM. Reminder, the purpose of this addition was simply to allow opkg authors to have RPM level dependencies so that when their RPMS are installed, they can have another fail-safe.
Proposed "semantics"/rules for the 'oscar-release' RPM: 1) The 'oscar-release' RPM will be a "core" package, therefore it will be available whenever "included" or "third-party" packages are installed. a. The server does all "core" opkg installs early on. b. The clients get all "core" & "non-core" opkgs installed at once, this could change with NEST but if it did it would likely fall to ordering similar to (a) -- "core" first, then "non-core".
2) The existence of the 'oscar-release' RPM simply enables an opkg author to gurantee that their RPMS for a particulare OSCAR version(s) will work (they can check the oscar version, that's all).
3) The existence of the 'oscar-release' RPM does not enable an opkg author to assume any particular phase of OSCAR, other than the phase in which RPMS (or Debs, etc.) are installed. (With the slight caveat that 'oscar-release' will always be there/available for non-core packages.)
I think that covers it fairly well. I agree that we might want to have a central "oracle" that we could inquire about the 'stage' of the OSCAR install but I don't think 'oscar-release' needs to do this. I also, think that such an "oscar-status" entity would be better fit at the OSCAR Database level. Since, we walk through the steps and write to the DB anyway, no new mechanisms are needed, just a hook to inquire about the status.
Lastly, I realize that the user could be confused that 'oscar-release' is installed but OSCAR isn't fully installed, but if they couldn't get the "Install Server" and "Build Client" steps to work, the log will show that and one RPM shouldn't be any more mystifying than a failing OSCAR Wizard. (Note, this RPM is mainly for opkg authors.)
Ok, fire away. ;) --tjn
_________________________________________________________________________ Thomas Naughton [EMAIL PROTECTED] Research Associate (865) 576-4184
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Oscar-core mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-core
-- {+} Jeff Squyres {+} [EMAIL PROTECTED] {+} http://www.lam-mpi.org/
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
