Bastian, Firstly, sorry for the late reply. This e-mail got lost in my inbox, my bad! :-(
On Mon, Jan 7, 2019 at 4:09 PM Bastian Blank <wa...@debian.org> wrote: > > On Fri, Dec 07, 2018 at 10:45:31AM +0100, Fabiano Fidêncio wrote: > > Although the subject says it all, let me explain the background of the > > change so you all can get the idea of why it'd help a few projects > > and/or even come up with a better solution than adding a ".treeinfo" > > file. > > I'm not exactly sure what you expect from this. Maybe it would be > easier if you provide a complete example, including information for at > least one non-mainstream architecture. Does aarch64 counts as non-mainstream architecture? If so, here's one example: http://mirror.vutbr.cz/fedora/releases/29/Server/aarch64/os/.treeinfo About "not exactly sure what you expect from this", virtualization management apps (like virt-manager) can perform a "network based" installation taking as parameters only the "location". The location, for the specific debian stable case is: https://ftp.us.debian.org/debian/dists/stable/main/installer-amd64/ and, from this location, there's some hardcoded assumptions in the code about where the kernel + initrd could be found and from there virt-manager knows what to do. We, as libosinfo, already have the information about the "location" and where the kernel/initrd are stored, this is cool and works as expected. However, one thing that we try to do is given a URL, we try to guess the OS from the URL and return the proper OS (and its version) to apps like virt-manager, so virt-manager can do things like perform an express installation (preseed installation) ... With the current situation, there's nothing we (as libosinfo) could look at and try to figure out which version of Debian we're dealing with (and, then, provide the info about resources to be used and what not), thus the suggestion to have, under https://.../installer-amd64/ the ".treeinfo" file that could help us to properly detect which system we're dealing with and, mainly, provide the correct information for apps like virt-manager. Is this more clear? I mean, the expectations and the whole reasoning behind my e-mails? > > > [1]: > > http://download.opensuse.org/pub/opensuse/distribution/leap/15.0/repo/oss/.treeinfo > > [2]: http://mirror.vutbr.cz/fedora/releases/29/Server/x86_64/os/.treeinfo > > [3]: http://mirror.centos.org/centos-7/7/os/x86_64/.treeinfo > > How do you detect those special paths? Because you already need to know > them somehow. Those are part of osinfo-db. So, for every new debian release we'd add a new debian entry and in the entry you can see something like: https://gitlab.com/libosinfo/osinfo-db/blob/master/data/os/debian.org/debian-testing.xml.in#L45 So, from this we can already tell mgmt apps the debian-testing URL and from where they should get the kernel + initrd in order to boot. However, if a custom URL is passed to libosinfo there's no way we could detect it as a "debian-testing" URL as we do not know what we should look for to ensure that. Do you get what I'm trying to say? Basically, we can't start parsing URLs in order to try to detect OSes, we should do that based on something *under* the path passed (https://.../installer-amd64) that we could just try to parse and ensure "it's a debian9". The .treeinfo idea was suggested mainly because it's been already used in other places (as pointed out by the examples above), but I'd be more than happy to adapt libosinfo code to check for something else as long as we know what to check for. > > Bastian > > -- > Hailing frequencies open, Captain. > Best Regards, -- Fabiano Fidêncio
