Re: Would be possible to have a ".treeinfo" file added to the installers' page?
On Tue, Jan 22, 2019 at 3:02 PM Fabiano Fidêncio <fabiano@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 <waldi@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
Reply to: