On Mon, Dec 19, 2016 at 01:18:13AM +0000, Ian Jackson wrote: > I get a sense of puzzlement from your mail. I will try to explain why > I want these seemingly-daft things. My puzzlement comes mostly from you seeming to have a very clear idea about what you want (= the Origin and Codename field of Release file), but its completely unclear what you have in hand to get there and why you actually want those instead of considering other ways. > 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 (The description of M-A:allowed is wrong – or at least very misleading. It is neither responsible for the ':i386' nor does it mean that different builds exists – and libc6 is like the worst possible choice as an example for an M-A:allowed packages because it neither is one nor can reasonable be ever be one… It would be /slightly/ more correct with M-A:same (which libc6 is), but in all honesty that whole sentence hurts more than it helps – in general that manpage could benefit from review as it is littered with typos [yuu, teporary, Kf, …] and incorrect or misleading info [M-A, what you call "alias" is "suite" (or "archive", but that might confuse people more than it helps), you redefine "suite", …]) From that I am assuming you have a binary package name as the start. Good – you can get the installed version (if any) from it, the source package (and version) it was build from and if you are lucky also the repository it was downloaded from (if the system is fully up-to-date and there aren't multiple choices due to multiple versions having the same number… – a common problem actually with people having a way of easily building packages with a few additional changes). You might be unlucky and the user has a version installed which isn't available (anymore) anywhere as the mirrors carry a new version already (or she has a previous selfbuilt installed, picks backports by hand, …) and that is were your trouble begins as things get complicated fast: binary packages change the source package they belong to (recent example: gnupg), source packages have a different version than the binary packages they build (classic example binNMU, but e.g. libgpg-error used to, too), multiple versions can exist in one repository, multiple repositories can contain packages with the same version number (but distinct content), … btw: Looking at the sources.list is bound to fail. That file might not even exist on many machines (e.g. on mine) and even if it would many repositories have a different release schedule then the one they "extend" (as in you will frequently have them refer to 'oldstable' if you upgraded to the 'new' stable sooner than the repository owner. A far more predictable way is e.g. looking at /etc/os-release. dpkg-vendor can also help you figuring out where you are. Packages itself can also have an Origin field in the dpkg/status file – that is only used by dpkg itself ATM through. The changelog of a package (if available!) can also help you identify from which pocket it came: "Normal" stable, -security and -backports have different entry points. Either seems for me far more simple and reasonable than trying to guess for each individual package from which repository it eventually came… Frankly, I have to question the whole interface a bit with its insistence on ",-security" (and what about -proposed-updates, …) and a soft suspicion that I can't get Ubuntu sources on Debian or more delicate: get foodistro/stable and bardistro/stable on Debian/stable as they all will be "stable" – but I am not a user, I just skimmed the manpage… > 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.) "all information" from the Release files is available via the 'apt-get indextargets' interface for the relevant files (see next-next section). > 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. You can pin entire suites and some suites come with pins by default, like experimental. A user will install a package from experimental semi- explicitly (as depending on the package manager used that might be more or less easy). Similar for backports. That the user picked a package from such a suite is lost at the end of the installation. What is considered a valid upgrade from that version in the future is again package manager dependent and non-trivial to figure out in the general case, so if the version you are "running" isn't available online anymore you are going to either error out or reimplement the logic of your preferred package manager alienating users of others. I would envision that as outlined before to be a relatively common situation in which I have some "old" version installed (which I might have patched so isn't available online anywhere anyhow) and a new version is available online I want to patch before installing. > > 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 Nothing protects you from this. You may increase complexity here by having the same version in multiple repositories – that will also teach you to stop talking about codenames and suites as if that would exist for all repositories (or a "correct" Origin value…). On the upside in the example code I gave all these situations will produce a line and you can let it give you any info available in the Release file – I would suggest looking at the output of the command and the documentation in /usr/share/doc/apt-doc/acquire-additional-files.txt > 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. Don't use 'apt' in scripts. And as said above all info is available anyhow so you don't need to correlate anything. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature