[haiku-development] Re: What for does SAT solver needed for package management?
- From: Kurtis Mullins <kurtis.mullins@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 18 Jun 2012 14:11:28 -0400
This is one of the fundamental problems of computer science. Unfortunately,
there is no method out there to pre-determine how a program will run, until
it's physically ran and the IO is compared. Even then, that could be an
anomaly and statistics could give a probability based upon the number of
runs. If a computer could perform this functionality, then the
infinite-loop problem wouldn't exist.
Based upon this, there's no guaranteed method to allow a computer to
determine whether or not a future (or previous) version of a particular
dependency will be compatible with the software. One small change in a
dependency may break all depending software (regression). Even if the
applications builds successfully with a version (or historical) revision of
the dependency, there may still be an incompatibility between the two.
Therefore, human involvement is required one way or another. There may be
ways to reduce the amount of work required by actual people. For example,
extensive automated testing with each application using variations of its
dependency-chain versions. However, I like the way that (I believe) Arch
handles packaging -- always use the latest packages (rolling releases) that
are known to work together. The downside is that it's difficult to install
a single package file without having access to its dependencies.
Not much of a suggestion -- but a thought.
- Kurtis Mullins
On Mon, Jun 18, 2012 at 1:15 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> Joseph Groover wrote:
> > Should PackageBuilder handle dependency generation itself?
>
> No.
>
> > When I create an package, the builder can go through the symbols and
> > determine what packages I have installed on my system are required to
> > satisfy those dependencies. It can even determine system dependencies
> > if the ABI broke due to some terrible bug at some point...
>
> AFAIK rpm can (not sure, if it always does) check executables and
> libraries for libraries they depend on and automatically add those as
> dependencies when building a package. Since the tool doesn't know the
> versioning scheme of the dependencies, it cannot be precise enough, though.
>
> > THEN, it could ALSO generate DependencyPackages which are correlated
> > with repository packages which have been identified as having dependents
> > so as to never be removed. The dependent symbols are logged for each
> > and every package with dependencies.
> >
> > When a new version of a package with dependents is uploaded, the old
> > version is compared - automatically - to the new one to identify if
> > dependent symbols have changed to an incompatible state. If so,
> > dependent packages currently in the repository will need to use the old
> > version, and future versions will need to run a symbol check to see
> > which version they need.
> >
> > This way, most of the load is handled by the server and the developer.
> >
> > When I install a package, the solver simply asks the server for the list
> > of dependencies, which is easily solvable through ABI branching per
> > updated dependencies, and the PackageInstaller/fs can then directly
> > resolve them by checking if they are installed already (and which
> > version - by ABI) and continue very rapidly.
> >
> > That is what I think would work the best... or am I missing something?
>
> This sounds rather complicated and error prone (how do you know which
> symbols make up the public interface?). It's also incomplete since matching
> symbols are only one part of the compatibility issue. E.g. in C interfaces
> function parameters aren't mangled into the symbol name, so they can change
> undedectably. Same issue with C++ function return types. But even a
> matching signature doesn't mean that the behavior remains compatible. So
> the system needs manual support anyway.
>
> The way we intend things to work is this: The packager (the person doing
> the packaging) writes a build recipe for a package which contains all the
> meta information for the package (name, description, license, exported
> resolvables (including a backward compatibility specification),
> dependencies,...) as well as all additional information needed for building
> the package. The package building tool (currently haikuporter) builds the
> package from the sources (i.e. compiles/links/generates files and puts them
> into a package (or multiple packages)). It does that in a clean chroot
> environment where only the specified dependencies are installed. This way,
> if it builds, at least the library dependencies should have been declared
> completely.
>
> Whether future versions of dependencies match is really a question of
> packaging those dependencies correctly. It's something that perhaps can be
> assisted by a tool comparing the symbols -- though I'm unsure whether that
> would work well in practice -- but in the end it's a matter of declaring
> the resolvable versions and backward compatibility correctly. That is
> something a tool cannot do on its own.
>
> CU, Ingo
>
>
Other related posts:
