[haiku-commits] Re: haiku: hrev50723 - src/tools/get_package_dependencies src/kits/package src/tools/create_repository_config build/jam src
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 09 Dec 2016 23:55:28 +0100
On 12/09/2016 07:32 AM, kallisti5 wrote:
On 2016-12-09 00:02, Adrien Destugues wrote:
On Thu, Dec 08, 2016 at 10:31:48PM +0100, Ingo Weinhold wrote:
In order to do this (even before these changes) you need to:
- Build the package
- Upload it to the repo using "jam build-remote-test-repository'
- This creates a repo matching the repo definition file in local Haiku
sources
- Then build using that repo (which downloads the package again)
So, as far as I know, building with packages not commited to a repo,
never actually worked, and we already have support to build a repo
without committing the changes.
Correct as far as I know as well.
It seems this particular feature hadn't been documented/communicated
well enough. Yes, it used to be possible to build a Haiku image with
only locally updated packages. Since packages already present in
download/ aren't downloaded again, copying the new package there would
suffice to prevent accessing a not yet valid repository URL.
While looking through this I saw there were lots of good intentions (a lot
undocumented) to the design of the repos, however it just ended up being a
plate of spaghetti in some spots.
A good example was that the "pseudo url" ended up being used in core
aspects of the build. (get_package_dependencies)
I'm pretty sure it wasn't on purpose, but more a matter of forgetful
convenience
at the time.
To clarify: The URL in the repository info/repository file *was*
supposed to be the actual base URL of the original (as opposed to
"mirror") repository. In case of the get_package_dependencies and the
HaikuPorts repository this meaning was just taken literally. I guess the
(non existent) API documentation should have made clear that the URL is
really just meant as an identifier and shouldn't be used as a URL.
I literally had to diagram the differences between a
BRepositoryInfo, BRepositoryConfig, BRepositoryCache to finally figure
out what was going on.
https://dev.haiku-os.org/attachment/ticket/12917/haiku-repo.png
Admittedly initially I found the various BRepository* classes a bit
confusing as well, though TBH I find your diagram even more
confusing/misleading. An attempt at simple definitions:
Repository info: A repository's meta data (name, vendor, architecture,...).
Repository file: A file containing the repository's data, which consist
of a repository info and the relevant meta data of all packages (package
name, version, dependencies, etc.) the repository contains.
Repository config: A package manager's reference to a repository added
by the user, consisting of name, URL, and priority (implying the order
in which repositories are searched for packages).
BRepositoryInfo: A class whose instances represent a repository info.
BRepositoryCache: A class whose instances refer to a client-side cached
repository file.
BRepositoryConfig: A class whose instances represent a repository
config. They may refer to a repository config file.
While there is a textual representation of a repository info, a
BRepositoryInfo doesn't refer to a repository info text file. One can
e.g. get a BRepositoryInfo from a BRepositoryCache.
A repository file -- not a BRepositoryCache instance -- is created from
a repository info and a set of package files. BRepositoryCache lives on
the client side only.
CU, Ingo
Other related posts:
