On Tue, Jan 22, 2019 at 3:02 PM Fabiano Fidêncio <fabi...@fidencio.org> wrote: > > 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
Ping? -- Fabiano Fidêncio
