[Sending to mailing list. CC'ing to non-yet-subscribed adresses. Please subscribe before answering.]
On 09/23/2013 10:45 AM, Stephan Aßmus wrote:
Ingo wrote:Maybe I should start by defining/explaining the basic terms we're talking about:[...]A repository can contain multiple packages with the same name and different versions, though that usually only makes sense when the packages are incompatible with each other (e.g. different major versions/ABIs), since otherwise the solver would always prefer the newer one.That appears to be a way to think about it, not a technological requirement, right?
That the solver prefers newer versions over old ones is a given. That there isn't much point in including e.g. both zlib-1.2.8 and zlib-1.2.7 is just a consequence of that, since zlib-1.2.7 will be silently ignored by the solver. You can probably explicitly tell the package manager to install it, but with the next general update it will be replaced again.
It does however make sense to include e.g. jpeg-9 and jpeg-8, since they are incompatible and the newer version is clearly marked as not being backward compatible. So another package requiring jpeg >= 8 will pull in jpeg-8 instead of jpeg-9. Since they wouldn't conflict, both could be installed at the same time.
In case that is what you are referring to, there is no technical restriction preventing a repository from including two compatible packages (even if their version differs only in the revision part, like zlib-1.2.8-2 and zlib-1.2.8-3). I just don't see why one would want to do that.
[...]Regarding the rolling release idea, it is rather important to think through how that is supposed to work with Haiku itself. As long as we're still creating regular release branches, the HaikuPorts package list files could possibly be updated automatically based on the stability votes. TBH, I'm a bit skeptical about that part, though.The Haiku images serve a purpose: * They help pin-point the revision that introduced a regression. * Someone can download an image and that can be the starting point for his Haiku installation. Obviously if we want to update Haiku installations via PM, the system as is wouldn't yet solve that problem, right? Each PM-enabled Haiku installation is connected to its specific repository. Updates would not happen unless someone actually breaks the rules and pushes updated packages into the repository for that Haiku revision.
Yes, though this won't even be possible, since the repository generation will happen automatically on the server side and after their creation the repositories are immutable (only the sys-admins could meddle with them). If you change the HaikuPorts package list in the Haiku source repository and push it to the server, you generate a new Haiku revision and also a new HaikuPorts repository.
While for regular Haiku master builds the URL of the matching repository would be pre-configured for the package manager, for release builds the URL of the "current" repository could be pre-configured instead, so the user could "pkgman update" to the latest set of packages right after installation (without having to change the configured repositories).
*Unless* of course the user configures additional repositories that serve another purpose than to provide a stable set of packages for a given Haiku revision, right?
Yes, the user can just configure another repository. We could even do a "current" repository for the master Haiku builds. By using that, people could just update to the latest master build.
*Or* the additional repository could be configured out of the box. So even when you build a specific Haiku revision, or have an old download somewhere and install that, immediately upon running it freshly, it would offer to update itself
Yes. As written above, for release builds that definitely makes sense, since I think people installing that will mainly be interested in running a stable version that they can easily update. For nightly master builds I'm not so sure. It seems convenient for testers or developers who want to keep their bleeding edge Haiku up-to-date -- they would only have to change the repository configuration only once anyway, though -- but ...
(which you may decline for testing purposes like pin-pointing a regression).
... this is significantly less convenient, if an issue has to be reproduced with a certain package installed that isn't installed by default. One would have to hunt down the matching repository URL first.
I don't see a problem with having these additional software channels in the form of official "unstable" and "stable" repositories that are constantly updated with new package versions. That way, both the build system knows what packages to download and include in the image, and PM can be used to update that system with newer packages. Now consider the scenario of automatically migrating packages between these additional repositories used for updating: Assume you have some POSIX software. Something in Haiku is fixed in order for that software to work better. A new package of that software is pushed to the unstable repository (and also any revision-based repository from that point on). But that package requires Haiku in that specific revision or newer. So even if a lot of users have that "unstable" Haiku revision (or newer) installed, and mark the POSIX package as working well via HaikuDepot(Web)... if it gets migrated to the stable repository by the system, it would not be installed (or even appear to the user), unless the Haiku version in the stable channel is at least the version which contains the fix needed by the package. Technically, that would work, no?
As long as all requirements and compatibilities are declared correctly that would work. However, I'd be very cautious regarding such an approach. The dependency resolution process can quickly become rather complex, even when there's only a simple in itself consistent repository. Throwing in multiple, possibly not even installable versions of packages will increase the complexity, likely to the point where the user is presented a problem list they cannot possibly understand anymore.
So I don't think deferring the integration of stable packages to the package solving process is a good idea. I think it should be possible to algorithmically check whether a package would be installable in principle, if added to a repository. So it might be possible to replace the older package version automatically. Or at least it should be possible to prepare a list of packages that can likely be migrated, so that someone can manually perform additional checks, if necessary, and apply the changes.
Now, whether or not the system can work, and can make regular releases superfluous, remains to be seen.
[...]I think it has become obvious that "big" releases don't work for Haiku. Whether it is possible or even desirable to do away with releases entirely, I'm not so sure. I could imagine that small and frequent (e.g. monthly) releases might work, provided that we can reduce the release overhead.
CU, Ingo
