----- Forwarded message from "Michael K. Johnson" <[email protected]> -----
Date: Wed, 9 Jan 2013 06:16:58 -0500 From: "Michael K. Johnson" <[email protected]> To: Foresight Linux Development <[email protected]> Subject: [Foresight-devel] Re: The new FL base system -- requirements, wants and wishes? On Mon, Jan 07, 2013 at 09:38:14PM -0500, Michael K. Johnson wrote: > Very much so. In general, being able to use binaries built for RHEL > (that is, having a compatible set of core libraries available even > if there are also newer libraries available) will make it more appealing > as a core OS. Questions arose on IRC as to what I meant by this. "core OS" isn't a technical term, it's just a descriptive term for the parts of the OS that will be generally installed no matter how the OS is being installed; server, desktop, whatever. My point about binaries built for RHEL is that if we have some common libraries *available* that are compatible with common libraries in RHEL, then conary dependency discovery will do a good job of pulling them onto systems where binaries that have been built on RHEL systems have been packaged. This is because Conary dependencies have far more information than RPM dependencies. Before system model, once a package was pulled onto a system for dependency resolution, "conary updateall" would keep trying to update it, and that could lead to update problems down the line. But with system model, if a package isn't listed to be installed and dependencies to it are dropped, then the package goes away. So putting into groups "available" packages with different library versions will make dependency resolution work and preserve upgrades. I'm very much not suggesting that some parts of the OS should be RHEL clones; that was part of my point about being able to move faster with new software versions. Having conary lets us move forward without breaking users who need to run older binaries. RHEL is just an example (the most likely one, given market share) of a set of libraries with which we'd like to be able to provide binary compatibility. _______________________________________________ Foresight-devel mailing list [email protected] http://lists.rpath.org/mailman/listinfo/foresight-devel ----- End forwarded message ----- _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
