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
> <zbys...@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
> > > <zbys...@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-Libraries-In-clang-lib-Package
[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.)
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
