On Wed, Apr 01, 2020 at 03:55:19PM -0400, Stephen Gallagher wrote:
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.
But in a way a Change Proposal does form a design document. I don't think anyone is asking for the complete implementation, but questions like this are fair at least to start thinking about the implementation.
* 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.
No.
* We could force all ELN builds to have epoch+100 when they rebuild (this has problems with future updates).
No need to modify the Epoch. And not advisable.
* 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.)
I don't like this approach because it alters expected behavior as a side effect. I don't think this needs to be overly complicated. What I would like is netinst install media for ELN where I can install it as a virt guest on my system. I do not want to live migrate a Fedora system to ELN nor do I want to mix ELN packages with Fedora packages on a system I am using. I want to be able to have a single ELN-only host that I can create and destroy as necessary. -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ 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
