We're worried about getting things installed that are legitimately (and rightly) required but not in the list already. That's what auto-dep-checking can help with.
Jason
At 05:25 PM 2/27/2003 -0600, Jeremy Enos wrote:
So it's even worse than I thought. Here is the problem I pointed out originally:
If foo.rpm depends on rpms which don't exist in that distro, we're hosed. I don't think this is a problem for ODA, because we control the Requires for it and and can require specific files. However, I don't think we can realistically put such a requirement on arbitrarily contributed packages.
Now the next problem that Jason's text reminded me of:
Even if all rpms did the "Right Thing" and depended on files rather than rpms, we're still left very vulnerable to getting hosed. Even w/ ODA for example. If ODA depends on /usr/sbin/mysqld, but MDK only has an rpm which holds /usr/local/sbin/mysqld, then the auto-dependency check would fail, no? And heck, even if it worked in that case, I guess we'd have problems anyway.
I don't know... I guess I'm just negative. ;-)
Jeremy
At 05:03 PM 2/27/2003 -0600, Jason B. wrote:At this point, if packages require something that is distro-specific, they can only be installed on that distro. Automatic dependency resolution would resolve either, because it would be looking at the packages that are there when finding dependencies for the package for that distro. In this way, packages requiring MySQL will only be able to resolve on Mandrake systems, and packages requiring mysql will install on RedHat systems.
If a package requires a commonly-located file, like a library (which aren't pathed in Requires), then auto-dep-checking will resolve to the right package for the distro available. The distro a package was built on is of little import unless it depends on distro-specific packages or files.
Jason
At 04:29 PM 2/27/2003 -0600, Jeremy Enos wrote:I have some concern that auto-dependency checking may be a pipe dream. RPM's can specify dependencies based on other files, or other rpms, no? The latter condition could be very problematic when going multi-distro. Suppose foo.rpm depends on bar.rpm, but foo was built on RH and bar doesn't exist on MDK.
mysql would be a real world example. It's got different rpm names and it's cut up differently among distros, so if rpms don't Require specifically by file, I think you'd be hosed. And I don't think it's realistic to demand that all packages must have rpms that specify Req's by file rather than by rpm, so let's not go there.
In the meantime, any ideas how we'd handle this problem?
Jeremy
At 10:14 AM 2/27/2003 -0500, Jeff Squyres wrote:On Thu, 27 Feb 2003, Benoit des Ligneris wrote:
> Another solution is automatic dependency checking. It can be complicated > and even not-functionnal because some RPMs packages provided by the > distro are broken. Anyway, I really believe that using an existing tool > (urpmi/autoupdate) can solve 99.9% of the problems...
I am a firm believer in using this auto-dependency checking stuff. urpmi and autoupdate are two obvious choices for this. I strongly feel that:
- OSCAR packages should only have to list their own RPMs - package RPMs should use the normal RPM dependency mechanisms to require other RPMs that they depend on
For example, the C3 RPM depends on python2. The C3 config.xml should *not* need to list python2 as a required RPM -- it's already specified in the C3 RPM spec (i.e., listing the same dependency twice is Bad, IMHO). So the C3 config.xml should just list the C3 RPM(s), and OSCAR should use autoupdate/urpmi/whatever to figure out that C3 also needs the python2 RPM.
If I recall what Jason sent to the list a few months ago, if you feed a list of RPMs to autoupdate, it can spit back an augmented list to you that has all dependencies resolved (it is not necessary to invoke this multiple times -- autoupdate does the whole recursive search to give you a fully resolved list back).
Autoupdate/urpmi/etc. have solved this whole dependency analysis problem for us, and we should use them. Using these tools is easy; its use provides great functionality for both OSCAR users and package authors.
Note that I am *not* talking about OSCAR packages depending on other OSCAR packages -- I'm talking about RPMs in OSCAR packages depending on RPMs that are not in other OSCAR packages (e.g., C3 and python2).
-- {+} Jeff Squyres {+} [EMAIL PROTECTED] {+} http://www.lam-mpi.org/
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
