Re: Proposal to use repo files in Anaconda environment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 17, 2019 at 03:09:01PM +0200, jkonecny@xxxxxxxxxx wrote:
> Hello everyone,
> 
> We (the Anaconda installer team) want to solve multiple problems by one
> solution and we want 
> 
> *YOUR FEEDBACK!*
> 
> 
> In short we are proposing to use custom repo files when configuring
> Anaconda for image creation instead of adding even more complexity to
> the kickstart repo command. For more details see the link below.
> 
> Purpose of this mail is to give everyone interested in the topic a
> place to discuss our proposal to find out if we didn't miss something
> or better case, if you agree with it :). It could be that this is not
> applicable for Lorax / Pungi / live-cd tool in that case please write a
> response to the document.
> 
> You can read details here:
> 
> https://hackmd.io/@prJIqOTeSxC-W0RNGKIGbQ/ByzIz3kIH/edit
> 
> Please, all the relevant comments should stay in the document if
> possible. If that solution won't work because of higher traffic then we
> will find a better solution but the point is to have everything on one
> place.

Sorry, I really don't like the hackmd.io thing, we regularly use email
for discussions like this and should continue the discussion on the
feoora-devel list.

With an updates.img solution like you are describing here is there anything
to be done? Can't it already drop new repos into /etc/yum.repos.d/ or
/etc/anaconda.repos.d/ ?

With my lmc patch for certs I am doing something like this, but only
with the cert files, not the repo files. updates.img

https://github.com/weldr/lorax/pull/839

>From the perspective of lmc no-virt mode and lorax-composer (which
use anaconda directly) it would be most useful to add a --repo and/or
--repodir cmdline option to anaconda that adds the repos to the dnf base
object, similar to the way that lorax does things:

https://github.com/weldr/lorax/blob/master/src/pylorax/dnfbase.py#L114

updates.img doesn't help with these use cases.

I totally agree with the goals here, the repo command in kickstart is
getting too long, but we need a way to handle special cases where people
need access to more of the dnf options.

At the same time I'm worried about the loss of information that this can
cause. Although I don't want to just dump dnf repo files into kickstart
-- that defeats the purpose of making it (somewhat) disconnected from the
specific backends like yum vs dnf.

Another option may be to use %pre to write out the repo files (I'm not
sure if anaconda will currently pick those up, but it should be possible
to fix if it doesn't).

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux