On Mon, Mar 11, 2019 at 02:50:44PM -0500, Jason L Tibbitts III wrote:
"VO" == Vít Ondruch vondruch@redhat.com writes:
VO> In this case, if DNF said something like "you have installed VO> foo-1:1.0, but there is available foo-0:2.0" it would give me VO> hint. From the start it would be annoying, but once we would reach VO> the point 4, I would, at least, know that I should do distrosync or VO> something.
Under the proposal I put forward:
No releases except for rawhide would ever be affected by this, assuming that users upgrade using supported methods.
Rawhide users would need to do this exactly once per cycle, on an announced date.
So you would know that you should do distrosync because that would be announced.
This doesn't sound convincing at all. We *know* that people miss announcements all the time. Dropping epochs would introduce yet another case where a "magical" step is needed at a specific time.
We need to remember that dropping epochs also impacts any package which uses Requires/BuildRequires/Recommends/Conflicts/Obsoletes on the package dropping the epoch.
Elsewhere in the thread people raised: - koji-shadow - external build systems - third party repos - custom packages
All those will require periodic rebuilds. The problem is that those things don't necessarily follow the cadence of Fedora releases. The proposal to drop epochs sounds like a step that is problematic and causes extra work now and ongoing for third-party packagers. And the problem that it solves is niche. The cost of the solution doesn't seem justified.
Zbyszek