[haiku-commits] Re: haiku: hrev50723 - src/tools/get_package_dependencies src/kits/package src/tools/create_repository_config build/jam src
- From: kallisti5 <kallisti5@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 09 Dec 2016 00:32:55 -0600
On 2016-12-09 00:02, Adrien Destugues wrote:
On Thu, Dec 08, 2016 at 10:31:48PM +0100, Ingo Weinhold wrote:
On 12/02/2016 10:20 AM, Axel Dörfler wrote:
> Am 02/12/2016 um 07:41 schrieb kallisti5@xxxxxxxxxxx:
> > * Once this stuff smooths out, we'll add UUID's to the
> > repo definitions for duplicate repo detection.
>
> Why didn't we simply take the URL as "pseudo" URL, ie. as identifier
> that does not reflect the actual URL? Much more pleasant to look at than
> a UUID, anyway.
As I already pointed out in the ticket, that's what it was intended to
be.
The URL of the original repository was used for sake of simplicity.
AFAICT
renaming/aliasing the attribute would have done the trick.
.
.
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.
As it looks (please correct me, if I'm wrong), the commit breaks
building
Haiku with packages not yet committed to a package repository, since
now
get_package_dependencies downloads repository caches from the given
repository URLs. One of the design goals of the build system
integration
was, that it should be possible to build and test Haiku with a new
package
(particularly one of those used by the base system (like ICU))
*before*
actually committing the package to the package repository.
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. 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
The fewer core 'required' things the repo definition has the easier it
will be
to grow the features of repositories in a non-breaking way.
The rest of the fields are pretty simple. Lets not try to use a url as a
UUID. At the end that is all it is... a random identifier of the
uniqueness
of a repository that end users will never see.
<rant>
I'm going a bit big-headed for a second, my day job is literally this
stuff.
(DevOps + Ops. Huge Red Hat Satellite Server deployments, custom ubuntu
apt
repo build pipelines, (yay aptly) etc).
This stuff can get crazy + confusing enough without worrying about
references
to detailed repo URL that "that aren't really URL's and shouldn't be
actually
used except for repo uniqueness"
</rant>
Anyway, those are my feels on this stuff.
-- Alex
Other related posts:
