On Mon, Mar 11, 2019 at 02:50:44PM -0500, Jason L Tibbitts III wrote: > >>>>> "VO" == Vít Ondruch <vondruch@xxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
