--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
It is worth noting that on Mandrake 8.2 rpm -q --provides MySQL returns:
msqlormysql =20
MySQL-server =20
mysqlserver =20
mysql =20
MySQL =3D 3.23.52-1.3mdk
And rpm which 'Requires: mysql' will properly be satisfied by this rpm on
Mandrake. AutoUpdate would Do The Right Thing (tm) in this case.
-Sean
On Thu, Feb 27, 2003 at 05:03:27PM -0600, Jason B. wrote:
> At this point, if packages require something that is distro-specific, the=
y=20
> can only be installed on that distro. Automatic dependency resolution=20
> would resolve either, because it would be looking at the packages that ar=
e=20
> there when finding dependencies for the package for that distro. In this=
=20
> way, packages requiring MySQL will only be able to resolve on Mandrake=20
> systems, and packages requiring mysql will install on RedHat systems.
>=20
> If a package requires a commonly-located file, like a library (which aren=
't=20
> pathed in Requires), then auto-dep-checking will resolve to the right=20
> package for the distro available. The distro a package was built on is o=
f=20
> little import unless it depends on distro-specific packages or files.
>=20
> Jason
>=20
> At 04:29 PM 2/27/2003 -0600, Jeremy Enos wrote:
> >I have some concern that auto-dependency checking may be a pipe=20
> >dream. RPM's can specify dependencies based on other files, or other=20
> >rpms, no? The latter condition could be very problematic when going=20
> >multi-distro. Suppose foo.rpm depends on bar.rpm, but foo was built on =
RH=20
> >and bar doesn't exist on MDK.
> >mysql would be a real world example. It's got different rpm names and=
=20
> >it's cut up differently among distros, so if rpms don't Require=20
> >specifically by file, I think you'd be hosed. And I don't think it's=20
> >realistic to demand that all packages must have rpms that specify Req's =
by=20
> >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 complica=
ted
> >>> and even not-functionnal because some RPMs packages provided by the
> >>> distro are broken. Anyway, I really believe that using an existing to=
ol
> >>> (urpmi/autoupdate) can solve 99.9% of the problems...
> >>
> >>I am a firm believer in using this auto-dependency checking stuff. urp=
mi
> >>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 requi=
re
> >> 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 u=
se
> >>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 t=
hat
> >>has all dependencies resolved (it is not necessary to invoke this multi=
ple
> >>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 OS=
CAR
> >>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
>=20
>=20
>=20
> -------------------------------------------------------
> 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
--=20
_______________________________________________________________________
=09
Sean Dague [EMAIL PROTECTED] http://dague.net
There is no silver bullet. Plus, werewolves make better neighbors than
zombies, and they tend to keep the vampire population down.
_______________________________________________________________________
--9jxsPFA5p3P2qPhR
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE+XrBWSamXem9TdyYRAmqjAJ9Vv/Hy+hlWBUYFlTi82VVf6IdozwCfdw4L
q2Ixgv39k0flm/CAXDBsTNQ=
=vmrg
-----END PGP SIGNATURE-----
--9jxsPFA5p3P2qPhR--
-------------------------------------------------------
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
