README: explain how to target a different suite with APT_CONFIG #16
Conversation
README.md
Outdated
|
|
||
| This is because ratt uses apt as configured on the system to resolve the reverse-build-dependencies. So if you target another suite that the one running on your machine, you need to tell `apt(1)` to use another configuration file. This is done using the `APT_CONFIG` environment variable. | ||
|
|
||
| Maintaining apt trees for various suites is out of scope for ratt. A common tool for the job is `chdist(1)`. So let's just assume that you're familiar with it, and you already have a sid distribution ready in your `~/.chdist`. Then you can easily fire ratt with this command: |
There was a problem hiding this comment.
It might be good to (briefly) state what use-case is solved by this configuration. IIUC, this is just an alternative to configuring sid + setting default-release to testing (or stable, if that’s your thing), yes?
There was a problem hiding this comment.
I thought the use-case was clear enough in the introduction line
Imagine you're running Debian buster on your machine, but you target Debian sid for the package you're working on.
I'm not sure I can word that better than by giving this example. Basically, the use case is that you run stable but build a package for unstable. Or the opposite, you run unstable and build a package for stable. But the point is: your apt is configured for the suite you run on your machine, and it is not configured for the distribution that you target when you build a particular package (which might change depending on what you're working on at the moment).
My first attempt at solving that was to run ratt inside a chroot (with the suite I target, ie. unstable), because it's what I would do if I build a package for another suite. But then I realised that ratt runs sbuild already, so it would end up being a chroot within a chroot, which made me think that, maybe, there was a better way. That's how I discovered APT_CONFIG.
IIUC, this is just an alternative to configuring sid + setting default-release to testing (or stable, if that’s your thing), yes?
I'm not sure, because I just don't use default-release, I just have my current suite (buster) in my apt config, and I don't configure apt at all basically. But I think you're correct, it's an alternative way of achieving the same thing.
To me, the point is just to document this use-case, because I think it's fairly common to target another suite that the one installed on your machine. The right way was not obvious to me, so I thought it might not be obvious to others (but I might be wrong).
If you're keen on documenting that, maybe we could name the paragraph something else, like "Targeting a different suite", which is actually a good name. And then document this way:
- start with the failure example I provided
- explain that maybe
-dis your way out (ie. you want to build the package for the suite installed on your machine) - otherwise, you need to make sure that the right apt files are available
- method a: modify your apt conf, and use default-release
- method b: use chdist and
APT_CONFIG
It makes for a longer explanation. It doesn't have to live in the README though, maybe you'd prefer to have that in the debian wiki. But I think it doesn't hurt, because ratt is a useful tool for new debian maintainers, they should be allowed to use it easily.
There was a problem hiding this comment.
It’s fine to document this in the README, I just wanted to understand where you’re coming from a bit more.
I agree that most people won’t run sid, and almost everyone will want to target sid. In my experience, just adding sid to /etc/apt/sources.list and setting default-release to prevent apt from using it is the most common configuration — the same technique is used for pinning / occasionally installing a package directly from testing/unstable (using e.g. apt install -t sid nginx).
As long as your PR mentions the apt route, it can also mention how to use custom apt configs for an alternative solution.
Does that make sense?
There was a problem hiding this comment.
Yep, let me re-word all of that, and we'll see if we're on the same page :)
There was a problem hiding this comment.
Pushed a new version. Once again, feel free to re-word as need be, as I'm not a native, so my words are clumsy here and there.
Signed-off-by: Arnaud Rebillout <[email protected]>
I think it's nice to have this little explanation, as it's a common use-case (for people using ratt on their own machine). There's already the issue #10 opened about this, where you mention that apt can use a different configuration file. That's what put me on the track actually, otherwise I had no idea how to handle this situation with
APT_CONFIG.Feel free to re-word if needed.
Thanks!