On Mon, Mar 11, 2019 at 02:50:44PM -0500, Jason L Tibbitts III wrote:
>>>>> "VO" == Vít Ondruch
<vondruch(a)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:
1. No releases except for rawhide would ever be affected by this,
assuming that users upgrade using supported methods.
2. 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