On Wed, Apr 1, 2020 at 3:24 PM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
>
> On Wed, Apr 01, 2020 at 11:40:49AM -0400, Stephen Gallagher wrote:
> > On Wed, Apr 1, 2020 at 6:46 AM Zbigniew Jędrzejewski-Szmek
> > <zbyszek@xxxxxxxxx> wrote:
> > >
> > > On Wed, Apr 01, 2020 at 12:30:13PM +0200, Miro Hrončok wrote:
> > > > On 01. 04. 20 10:53, Zbigniew Jędrzejewski-Szmek wrote:
> > > > >On Tue, Mar 31, 2020 at 11:31:38AM -0400, Stephen Gallagher wrote:
> > > > >>I sent out the V2 version of the Change on Friday and then promptly
> > > > >>managed to injure myself and be away from email until today. I've read
> > > > >>through the email threads again this morning and I decided that,
> > > > >>rather than try to address them one by one, I'd try again with a V3
> > > > >>that hopefully answers some of the repeated questions and concerns on
> > > > >>that list.
> > > > >
> > > > >>To enable ELN (once the repository is composed):
> > > > >>
> > > > >>$ dnf install fedora-repos-eln
> > > > >>$ dnf distro-sync
> > > > >
> > > > >I don't see this part explained. Those additional packages will haves
> > > > >NEVRAs always lower than rawhide packages (".eln" < ".fc33".). So this
> > > > >distro-sync will be a noop?
> > > >
> > > > A wild guess: If that repo has lower "cost", will distro-sync prefer
> > > > packages with lower EVR because they come form that repo?
> > >
> > > I don't think so: "cost — ... It is useful to make the library prefer
> > > on-disk repositories to remote ones."
> > >
> > > But there's a "priority" option: "If there is more than one candidate
> > > package for a particular operation, the one from a repo with the
> > > lowest priority value is picked, possibly despite being less
> > > convenient otherwise (e.g. by being a lower version)."
> > >
> > > This should do the trick. The mechanism should be described in the
> > > Change page too.
> > >
> > > (Note: I had a sense of deja-vu, because 'priority' was already
> > > discussed in the context of this Change, but it was koji priority for
> > > scheduling tasks, not package installation.)
> >
> >
> > Right, the intent here is to have the fedora-repos-eln subpackage
> > provide a repo at priority level 98 (default being 99, lower numbers
> > "win"). I left it out because generally Change Proposals aren't
> > required to document every minor implementation detail.
>
> It's not a minor implementation detail. The subject of priority came
> up before in the thread where people were wondering about version
> ordering. What priority level will be used is indeed something that
> doesn't need to appear in the change page, but the general approach
> should IMO appear there.
>
> By providing an overview of implementation choices you make it
> possible for people to think about various corner cases and possibly
> find issues that that otherwise could only discover once the
> implementation is done and it's much harder to change stuff.
Well, Change Proposals aren't design documents. I would prefer to
change the document to read more like "This will need to be
implemented in such a way that contents of the ELN repository would be
preferred by the software management tools over the standard Fedora
packages, even when the latter are of a higher version." I prefer not
to put implementation details in places like this; I'd rather describe
the expected behavior and trust that those implementing it will find
an appropriate mechanism.
Do you want me to list some of the other approaches we considered and
discarded before we settled on `priority`? I don't think that belongs
in a Change Proposal either, but since apparently we can't get Changes
approved anymore without having the complete implementation
beforehand, I guess we can add that too.
* Instead of using `priority`, we *could* opt to provide all of the
ELN content as a large Module. That has overhead problems that make it
not worthwhile.
* We could force all ELN builds to have epoch+100 when they rebuild
(this has problems with future updates).
* We could modify the RPM/libdnf stack to automatically install
different versions of the RPMs based on available hardware. (We don't
have the available resources for another Modularity-level effort.)
_______________________________________________
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
