IMPORTANT: Repository changes

#1

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.

https://www.haiku-os.org/guides/daily-tasks/updating-system.html

tldr version:

nightly / master?

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.

Updating Haiku, refreshing repository failed!
#2

Can I translate and post to my blog? clear giving the due credits, and linking the original poust.

#3

Of course. Spread the news! :slight_smile:

#4
#5

The r1beta1 has /master/ in it for haikuports. Is that intentional?

#6

Yes, AFAIK. Haikuports hasn’t (yet?) created a beta branch.

#7

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?

#8

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

#9

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.

#10

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?

#11

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)

#12

Sure, but who would do all that tedious work?

#13