Hi, Quoting Antoine Beaupré (2024-12-29 16:44:41) > On 2024-12-23 07:49:57, Johannes Schauer Marin Rodrigues wrote: > > If this variable were to be re-used then somebody who intends to build for > > bookworm-backports would have a chroot for just bookworm, without backports > > extracted. That is wrong. > Is it really? I mean if you don't have a bookworm-backports tarball, you > don't, and you fallback to plain bookworm, that seems fine to me: you're > building your backport without any other possible backports deps, and it > might fail, but if it's a leaf package without any extra deps needed from > backports, it's actually fine.
you have to weigh different things against each other. You say that it's not that bad. I'm saying that creating an extra tarball is *also* not that bad. And in my mind, creating an extra tarball is less bad than having the surprise that building for bookworm-backports is not done inside a chroot that has bookworm-backports by default. > And if it fails, then you just make a new backports tarball. Yes, which is an extra step that is avoided by just creating an extra tarball by default. So yes, a few hundred megabytes and a few seconds of creation time extra because an existing tarball is not re-used is bad. But I find it even worse to have the default be: then just create a new tarball manually. > > Instead I think what you need here is what aliases used to be for schroot > > and that would be a new mapping option which would replace the symlink > > mechanism. > > > > Does that make sense? > > I think I understand where you're coming from, but I think you're > overthinking this and the existing mechanisms are fine, provided that > you can always fallback to "just make a new tarball". Oh I'm absolutely overthinking this. Stuff that I put into sbuild today will literally be used by people 10 years in the future. Thinking about that makes me overthink this all the time. That being said, you said in your initial mail that > The build works, so it's not *that* bad, considering how fast mmdebstrap is, > but it would sure be nice to skip that step entirely. so this is just a wishlist feature. I think it's a nice wishlist feature and I think it absolutely makes sense to have a variable mapping UNRELEASED to unstable by default, similar to how aliases worked before in schroot. Thanks! cheers, josch
signature.asc
Description: signature
