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(a)in.waw.pl> 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(a)in.waw.pl> 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.
I disagree, both to "aren't design documents" and to the usefulness of
providing detail.
Change pages often describe what will happen in detail. Just look at
any of the pages from F32 list, e.g. [1-5]. The ones that don't
describe implementation details are usually straightforward changes
like gcc/binutils/dnf/language stack version bumps where the packaging
changes are trivial.
In fact, for [4] below I had to provide the complete list of affected
packages in the fesco ticket, and I think it was totally appropriate.
[1]
https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer
[2]
https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks
[3]
https://fedoraproject.org/wiki/Changes/Stop-Shipping-Individual-Component...
[4]
https://fedoraproject.org/wiki/Changes/Systemd_presets_for_user_units
[5]
https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format
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.
Yes, I think it'd be totally OK to describe alternative approaches
and their relative merits. For something as complicated as this Change,
airing design choices in public discussion should be a completely obvious
step.
I *want* this change to succeed, but a lot of the discussion is people
simply clamoring for information, often without any immediate result.
I completely don't understand the reluctance.
Zbyszek
> * 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.)