Hi. Firstly, thanks for your attention. I appreciate you helping me make my code do the right thing, and not store up problems for the future.
I get a sense of puzzlement from your mail. I will try to explain why I want these seemingly-daft things. Right now, a dgit user can easily get the source code for the version of the package in sid. That's the default, in fact. However, a user who wants to change the behaviour of their own computer, which may well be running stable or even oldstable, probably does not want to take on a backporting task too. They want the source code for the version they're running. (Which as you allude to might be from -security or -backports.) Right now, users have to dig a bit to find the right information. Take a you look here at the advice under `Finding the Debian release': https://manpages.debian.org/cgi-bin/man.cgi?query=dgit-user&apropos=0&sektion=0&manpath=Debian+testing+stretch&format=html&locale=en I would like to make a way to a user to ask dgit for "what I'm running" (this request is #848193). You mention version numbers. Obviously the user wants the right version. But the version number is not sufficient. dgit provides a fast-forwarding git branch for each suite. To get the right history structure it is necessary to know not just the sequence of version numbers, but also any shared git history (from the dgit git server). I think all the information I need is in the Release file (assuming we can somehow identify what the right Release file is). That contains both the suite name and the codename, and also the Origin field tells us the distro. (dgit needs configuration for each distro anyway, so just the distro name is enough.) David Kalnischkies writes ("Re: Bug#848194: Want way to get Release (or InRelease) file from cache"): > On Thu, Dec 15, 2016 at 01:35:14AM +0000, Ian Jackson wrote: > > I would like a way to get the [In]Release file corresponding to the > > source from which apt got (or, I guess, would install) a particular > > package. > > Got vs. would is a HUGE difference – and the information of 'got' is > not stored anywhere so what you want to know is not possible, > especially if the system isn't fully upgraded yet and you have to > consider pinning (ignoring that users could be changing it at > runtime). You can approximate all this with guesswork, but the > amount of times you will guess wrong will make this whole endevour > borderline useless as a user will never be able to reasonably > predict what the result of a command issued will be (in my opinion > at least). I think it doesn't matter very much whether this new dgit feature gets "the version I am currently running", or "the version I would get if I let apt do the update". If the former information is not recorded (and I certainly couldn't find it anywhere when I looked) then the latter will do fine. As for pinning, I'm not sure exactly why that is a problem, but I think if the user has specifically pinned the very same package, they probably have some awareness of what's going on, so bugs where dgit gives them the wrong suite (or, situations where dgit some something slightly different to apt) are less bad. > Johannes Schauer had asked about the inclusion of Release files in > 'apt-get indextargets' a while ago. It's a slight stretch, but its the > only place where this would make sense & relatively easy to add. I think this could be a part of the solution. > | apt-get indextargets "Created-By: Sources" --format='$(FILENAME) > $(CODENAME) $(SUITE)' | while read file codename suite; do > | if /usr/lib/apt/apt-helper cat-file "$file" | grep-dctrl -q -PX apt -a -F > Version -X '1.4~beta2'; then > | echo "FOUND in: $codename ($suite) $file"; > | fi > | done What if the same package is available at the same version in multiple suites all of which appear in the apt sources ? I think this is the part I have to use `apt-cache madison' or `apt show' for. `apt show' contains an `APT-Sources' line which I could presumably correlate with indextargets. Regards, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.