We have been through several iterations of repository layouts and infrastructure changes. I noticed tonight that HaikuDepot was sensitive to these changes and whatever we were configured with in R1 Beta 1, we would be stuck with for a good-long-while.
I spent some time tonight cleaning up our repository URL’s since we have been a complete mess with them since PM was first introduced.
I feel like things are stable at this point, and depot.haiku-os.org has been adjusted to reflect the final repository design (which works for nightly rolling / master images as well as the upcoming R1 Beta 1.)
I have updated our upgrading guide with the steps needed to “align all historical installs” to the correct repositories. I’d recommend running through the steps.
pkgman drop Haiku; pkgman drop HaikuPorts
pkgman add https://eu.hpkg.haiku-os.org/haiku/master/$(getarch)/current
pkgman add https://eu.hpkg.haiku-os.org/haikuports/master/$(getarch)/current
r1beta1?
pkgman drop Haiku; pkgman drop HaikuPorts
pkgman add https://eu.hpkg.haiku-os.org/haiku/r1beta1/$(getarch)/current
pkgman add https://eu.hpkg.haiku-os.org/haikuports/master/$(getarch)/current
Any images installed going forward will use these repository locations, and I have them configured to (hopefully) be flexible enough to allow us to stick with their design for a good long while.
I’m not 100% we are going to branch haikuports for r1beta1 based on consensus. We’re still in beta, and users on the latest and greatest ports seems desirable vs having a stale ports branch (and more work).
Maybe master for r1beta1 and beyond… a branched haikuports for r1?
it shouldn’t be neccesary to branch the whole haikuports, just use compatibility flags on recipes incompatible with r1 but working on nightlies, like it is currently been done for building separate x86-gcc2 and x86_64 packages
I agree that we should not have a Beta HaikuPorts branch. Apps are constantly being updated and bug fixed.
The only caveat I would add is that the apps should go through a more stringent QA before being released.
Well, initially, we were going to branch HaikuPorts, and that seemed to be the decision we’d settled on. But maybe not branching makes more sense indeed; what do @pulkomandy and @extrowerk have to say here?
I think the current haikuports is too much “move fast and break things” and that’s unsuitable for a release. However, this does not mean I want something frozen with fixed versions and never an update.
I think what makes more sense is something similar to Debian “testing”. Recipes land in the master branch, and if after 15 days or no problem is found, they get into the release branch.
And we also need more tooling to detect problems (lib version/soname mismatch, replacing package with incompatible one, etc)
I have been attemting to update after changing the repo urls and keep getting stopped at haiku-r1~beta1_hrev52379-1-x86_gcc2
suftware updater says it failed to update, and pkgman update gets :
100% repochecksum-1 [65 bytes]
Validating checksum for BeSly Software Solutions…done.
100% repochecksum-1 [65 bytes]
Validating checksum for FatElk…done.
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku…done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts…done.
100% repochecksum-1 [65 bytes]
Validating checksum for KapiX’s Depot…done.
100% repochecksum-1 [65 bytes]
Validating checksum for clasqm’s repo…done.
The following changes will be made:
in system:
upgrade package haiku-r1~beta1_hrev52369-1 to r1~beta1_hrev52379-1 from repository Haiku
upgrade package haiku_x86-r1~beta1_hrev52369-1 to r1~beta1_hrev52379-1 from repository Haiku
upgrade package haiku_loader-r1~beta1_hrev52369-1 to r1~beta1_hrev52379-1 from repository Haiku
upgrade package webpositive_x86-r1~beta1_hrev52369-1 to r1~beta1_hrev52379-1 from repository Haiku
upgrade package makefile_engine-r1~beta1_hrev52369-1 to r1~beta1_hrev52379-1 from repository Haiku
upgrade package gzip-1.8-2 to 1.9-2 from repository HaikuPorts
upgrade package beshare_x86-2.35-2 to 2.35-3 from repository HaikuPorts
upgrade package libreoffice_x86-6.2.0.0~git-18 to 6.2.0.0~git-19 from repository HaikuPorts
upgrade package userland_fs-r1~beta1_hrev52369-1 to r1~beta1_hrev52379-1 from repository Haiku
upgrade package haiku_devel-r1~beta1_hrev52369-1 to r1~beta1_hrev52379-1 from repository Haiku
upgrade package netfs-r1~beta1_hrev52369-1 to r1~beta1_hrev52379-1 from repository Haiku
upgrade package haiku_x86_devel-r1~beta1_hrev52369-1 to r1~beta1_hrev52379-1 from repository Haiku
Continue? [yes/no] (yes) : yes
24% haiku-r1~beta1_hrev52379-1-x86_gcc2… 10.35 MiB/41.90 MiB 31.01 KiB/s *** Failed to download package haiku: Data read partially
One used to be able to requset a package with wget:
