On 5/3/19 8:56 AM, Fabiano Fidêncio wrote: > On Fri, 2019-05-03 at 13:07 +0200, Fabiano Fidêncio wrote: >> On Thu, May 2, 2019 at 4:39 PM Fabiano Fidêncio <fidencio@xxxxxxxxxx> >> wrote: >>> Tree based installations will require a kernel-url-argument to be >>> assed. Let's provide an API to the apps to get this info from >>> OsinfoOS. >>> >>> https://gitlab.com/libosinfo/osinfo-db/issues/28 >>> >>> Signed-off-by: Fabiano Fidêncio <fidencio@xxxxxxxxxx> >> >> I've discusses this with Cole off-list and we've decided that going >> for an "inheritance" (pero no mucho) way would be better. >> I'll change the implementation for something towards the line of: >> current.kernel_url_argument = current.kernel_url_argument or >> derived_from.kernel_url_argument >> >> With that we'll be able to keep kernel_url_argument as a single one >> and just replace it in case a new one is added (which will be needed >> for Fedora >= 19, for instance). >> >> A v3 (of the whole thing) will be submitted. > > Okay, I have this work done but before submit the v3, I'd like to raise > one possible issue and confirm that having this kind of duplication is > fine. > > In the v2, I've been using as part of the scripts something like: > <xsl:value-if select="os/kernel-url-argument"/> > > Once we start inheriting kernel-url-argument, the kind of call shown > above wouldn't be possible anymore, leading us to have, as part of the > scripts, something like (for RHEL): > <xsl:choose> > <xsl:when test="os/version < 7"> > <xsl:text> method</xsl:text> > </xsl:when> > <xsl:otherwise> > <xsl:text> inst.repo</xsl:text> > </xsl:otherwise> > </xsl:choose> > > This is duplication of info will be needed because not all the <os/> > entris will have the <kernel-url-argument/> attribute. > > IMO it still looks better in this way (please, check v1[0]) than having > to have the entry added in all OSes. > > Cole, what do you think? > Hmm yeah that's a bit unfortunate, but I think it's nicer than the kernel-url-argument duplication, so thumbs up from me Thanks, Cole _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
