Re: Would be possible to have a ".treeinfo" file added to the installers' page?
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
Reply to: