Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
On Fri, 2019-03-08 at 16:19 -0600, Jason L Tibbitts III wrote: > * Bodhi shouldn't be involved here as this would be restricted to > rawhide. Just a note that we do have plans to use Bodhi to manage Rawhide in the future, and will hopefully have it doing this in 2019. Bodhi is not currently Epoch-aware, but I wouldn't be opposed to teaching it about Epochs if we wanted to make a change in this area. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
On Mon, Mar 11, 2019 at 12:23 PM Neal Gompa wrote: > I don't remember how Plague handles this anymore (forgive me, but I > haven't interacted with Plague since 2005!), but both Koji and OBS > don't care if the Epoch goes up or down. Koji uses NVR as a key > (without Epoch), and OBS freely allows EVRs to go up and down. Some parts of Koji do rely on epoch not doing down. Notably, koji-shadow uses epoch and it will stop working correctly when epoch is removed or decreased. koji-shadow is not currently used by Fedora project, but it may be used in future to bootstrap new architectures. And it is still used by third parties to rebuild Fedora packages. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
On Mon, Mar 11, 2019 at 6:48 AM Stephen John Smoogen wrote: > > On Mon, 11 Mar 2019 at 05:29, Vít Ondruch wrote: > > > > > > Dne 09. 03. 19 v 15:37 Neal Gompa napsal(a): > > > On Sat, Mar 9, 2019 at 7:11 AM Vít Ondruch wrote: > > >> > > >> Dne 09. 03. 19 v 13:00 Vít Ondruch napsal(a): > > >>> Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a): > > > "MH" == Miro Hrončok writes: > > MH> On 08. 03. 19 21:16, Neal Gompa wrote: > > >> I really wish we'd allow Epochs to be reset on distribution upgrades. > > >> With dnf distro-sync (which is used by system-upgrade) Epochs don't > > >> really matter and upgrades work as intended anyway... > > MH> Let's do a Fedora change? Coordinate with FPC? > > > > We (FPC) have talked about this before but I don't think it's really up > > to FPC. The change process isn't really the right way to do it, > > either, > > since this is really a policy revision. I just think FESCo needs to > > decide whether or not it would like to relax the policy, and if so, > > how. > > > > Here are the relevant points as I see them (unless I'm forgetting > > something): > > > > * dnf system-upgrade generally handles versions going backward without > > issue. The specific case of epoch being reset is not an issue. > > > > * dnf upgrade would not handle this, causing problems for those running > > rawhide or using unsupported methods of upgrading between releases. > > > > * Those running rawhide would have to run distro-sync in order to > > upgrade (which would of course reset any locally built updated > > packages and such). They would have to do this every time any > > installed package drops epoch. > > > > * Those using an unsupported method of upgrading would need to > > incorporate distro-sync. > > > > * Dropping epoch outside of rawhide would generally be bad. > > > > * Koji and the compose process do handle things "going backwards", as > > this has happened multiple times in the past without things dying. > > What's important there is which version was most recently tagged. > > > > * Bodhi shouldn't be involved here as this would be restricted to > > rawhide. > > > > Personally I'm in support of relaxing the restriction in some form, but > > I prefer a single "drop Epoch: day" where epochs in rawhide are > > _automatically_ removed and the packages rebuilt. This gives a single > > point in time where rawhide users need to do a distro-sync in order to > > properly track updates. Allowing epochs to be dropped without > > coordination seems to me to be a burden on rawhide users, but I don't > > think a single flag day would be problematic. > > > > I would expect the first flag day to be busy. I see 756 Epoch: tags > > currently, though 161 are set to 0 for whatever reason. Afterwards I > > would expect no more than a small number of packages per cycle to > > acquire Epoch: tags. > > > > - J< > > >>> If DNF were helpful and was able to report packages, which has higher > > >>> NVR then E(NVR), > > >> > > >> I meant (E)NVR actually. > > >> > > >> > > >> V. > > >> > > >> > > >>> then I can imagine that reset of epoch could work. > > >>> Otherwise I am against resetting epochs. > > >>> > > > I'm confused, why would that matter? And DNF always reports NEVRA... > > > > > > > > > > The epoch are used in cases like: > > > > 1. There is foo version 1.0 > > > > 2. foo is updated to version 2.0, because it seems it is safe. > > > > 3. It is discovered, that it breaks stuff, so the decision is go back to > > 1.0 and add epoch. > > > > 4. Eventually, we really want to have 2.0 in the release or even > > something newer. Now, the epoch could be removed, but it is not > > possible, because it has the highest priority. > > > > > > In this case, if DNF said something like "you have installed foo-1:1.0, > > but there is available foo-0:2.0" it would give me hint. From the start > > it would be annoying, but once we would reach the point 4, I would, at > > least, know that I should do distrosync or something. > > > > Whatever changes to EPOCH rules will need additional logic added to > all the various buildsystem logic where a human can't sit around and > choose 'oh yeah I want to go to that older epoch' because the build is > automated somewhere. This has been the major reason why various 'EPOCH > should go back' or 'I want an EPOCH to my EPOCH' conversations in the > past have floundered (I think we last looked at this in 2009 and I > know we did in 1999.. so maybe this is a 10 year cycle?). There is a > LOT of stuff written on the assumption that EPOCH's go forward and > never backwards. Changing the rules here have effects in many many > other build systems and install tools which sites are
Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
On Mon, 11 Mar 2019 at 05:29, Vít Ondruch wrote: > > > Dne 09. 03. 19 v 15:37 Neal Gompa napsal(a): > > On Sat, Mar 9, 2019 at 7:11 AM Vít Ondruch wrote: > >> > >> Dne 09. 03. 19 v 13:00 Vít Ondruch napsal(a): > >>> Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a): > > "MH" == Miro Hrončok writes: > MH> On 08. 03. 19 21:16, Neal Gompa wrote: > >> I really wish we'd allow Epochs to be reset on distribution upgrades. > >> With dnf distro-sync (which is used by system-upgrade) Epochs don't > >> really matter and upgrades work as intended anyway... > MH> Let's do a Fedora change? Coordinate with FPC? > > We (FPC) have talked about this before but I don't think it's really up > to FPC. The change process isn't really the right way to do it, either, > since this is really a policy revision. I just think FESCo needs to > decide whether or not it would like to relax the policy, and if so, how. > > Here are the relevant points as I see them (unless I'm forgetting > something): > > * dnf system-upgrade generally handles versions going backward without > issue. The specific case of epoch being reset is not an issue. > > * dnf upgrade would not handle this, causing problems for those running > rawhide or using unsupported methods of upgrading between releases. > > * Those running rawhide would have to run distro-sync in order to > upgrade (which would of course reset any locally built updated > packages and such). They would have to do this every time any > installed package drops epoch. > > * Those using an unsupported method of upgrading would need to > incorporate distro-sync. > > * Dropping epoch outside of rawhide would generally be bad. > > * Koji and the compose process do handle things "going backwards", as > this has happened multiple times in the past without things dying. > What's important there is which version was most recently tagged. > > * Bodhi shouldn't be involved here as this would be restricted to > rawhide. > > Personally I'm in support of relaxing the restriction in some form, but > I prefer a single "drop Epoch: day" where epochs in rawhide are > _automatically_ removed and the packages rebuilt. This gives a single > point in time where rawhide users need to do a distro-sync in order to > properly track updates. Allowing epochs to be dropped without > coordination seems to me to be a burden on rawhide users, but I don't > think a single flag day would be problematic. > > I would expect the first flag day to be busy. I see 756 Epoch: tags > currently, though 161 are set to 0 for whatever reason. Afterwards I > would expect no more than a small number of packages per cycle to > acquire Epoch: tags. > > - J< > >>> If DNF were helpful and was able to report packages, which has higher > >>> NVR then E(NVR), > >> > >> I meant (E)NVR actually. > >> > >> > >> V. > >> > >> > >>> then I can imagine that reset of epoch could work. > >>> Otherwise I am against resetting epochs. > >>> > > I'm confused, why would that matter? And DNF always reports NEVRA... > > > > > > The epoch are used in cases like: > > 1. There is foo version 1.0 > > 2. foo is updated to version 2.0, because it seems it is safe. > > 3. It is discovered, that it breaks stuff, so the decision is go back to > 1.0 and add epoch. > > 4. Eventually, we really want to have 2.0 in the release or even > something newer. Now, the epoch could be removed, but it is not > possible, because it has the highest priority. > > > In this case, if DNF said something like "you have installed foo-1:1.0, > but there is available foo-0:2.0" it would give me hint. From the start > it would be annoying, but once we would reach the point 4, I would, at > least, know that I should do distrosync or something. > Whatever changes to EPOCH rules will need additional logic added to all the various buildsystem logic where a human can't sit around and choose 'oh yeah I want to go to that older epoch' because the build is automated somewhere. This has been the major reason why various 'EPOCH should go back' or 'I want an EPOCH to my EPOCH' conversations in the past have floundered (I think we last looked at this in 2009 and I know we did in 1999.. so maybe this is a 10 year cycle?). There is a LOT of stuff written on the assumption that EPOCH's go forward and never backwards. Changing the rules here have effects in many many other build systems and install tools which sites are using and that usually ends up being too big of a problem to solve. [Yes we can fix our koji/bodhi/greenwave/waiverdb/pungi/mock/copr, and their koji and maybe that other other koji... but how do we fix the plague server building stuff at large industrial complex-1 or the clone of the OSBS at
Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
Dne 09. 03. 19 v 15:37 Neal Gompa napsal(a): > On Sat, Mar 9, 2019 at 7:11 AM Vít Ondruch wrote: >> >> Dne 09. 03. 19 v 13:00 Vít Ondruch napsal(a): >>> Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a): > "MH" == Miro Hrončok writes: MH> On 08. 03. 19 21:16, Neal Gompa wrote: >> I really wish we'd allow Epochs to be reset on distribution upgrades. >> With dnf distro-sync (which is used by system-upgrade) Epochs don't >> really matter and upgrades work as intended anyway... MH> Let's do a Fedora change? Coordinate with FPC? We (FPC) have talked about this before but I don't think it's really up to FPC. The change process isn't really the right way to do it, either, since this is really a policy revision. I just think FESCo needs to decide whether or not it would like to relax the policy, and if so, how. Here are the relevant points as I see them (unless I'm forgetting something): * dnf system-upgrade generally handles versions going backward without issue. The specific case of epoch being reset is not an issue. * dnf upgrade would not handle this, causing problems for those running rawhide or using unsupported methods of upgrading between releases. * Those running rawhide would have to run distro-sync in order to upgrade (which would of course reset any locally built updated packages and such). They would have to do this every time any installed package drops epoch. * Those using an unsupported method of upgrading would need to incorporate distro-sync. * Dropping epoch outside of rawhide would generally be bad. * Koji and the compose process do handle things "going backwards", as this has happened multiple times in the past without things dying. What's important there is which version was most recently tagged. * Bodhi shouldn't be involved here as this would be restricted to rawhide. Personally I'm in support of relaxing the restriction in some form, but I prefer a single "drop Epoch: day" where epochs in rawhide are _automatically_ removed and the packages rebuilt. This gives a single point in time where rawhide users need to do a distro-sync in order to properly track updates. Allowing epochs to be dropped without coordination seems to me to be a burden on rawhide users, but I don't think a single flag day would be problematic. I would expect the first flag day to be busy. I see 756 Epoch: tags currently, though 161 are set to 0 for whatever reason. Afterwards I would expect no more than a small number of packages per cycle to acquire Epoch: tags. - J< >>> If DNF were helpful and was able to report packages, which has higher >>> NVR then E(NVR), >> >> I meant (E)NVR actually. >> >> >> V. >> >> >>> then I can imagine that reset of epoch could work. >>> Otherwise I am against resetting epochs. >>> > I'm confused, why would that matter? And DNF always reports NEVRA... > > The epoch are used in cases like: 1. There is foo version 1.0 2. foo is updated to version 2.0, because it seems it is safe. 3. It is discovered, that it breaks stuff, so the decision is go back to 1.0 and add epoch. 4. Eventually, we really want to have 2.0 in the release or even something newer. Now, the epoch could be removed, but it is not possible, because it has the highest priority. In this case, if DNF said something like "you have installed foo-1:1.0, but there is available foo-0:2.0" it would give me hint. From the start it would be annoying, but once we would reach the point 4, I would, at least, know that I should do distrosync or something. V. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
On Sat, Mar 9, 2019 at 7:11 AM Vít Ondruch wrote: > > > Dne 09. 03. 19 v 13:00 Vít Ondruch napsal(a): > > Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a): > >>> "MH" == Miro Hrončok writes: > >> MH> On 08. 03. 19 21:16, Neal Gompa wrote: > I really wish we'd allow Epochs to be reset on distribution upgrades. > With dnf distro-sync (which is used by system-upgrade) Epochs don't > really matter and upgrades work as intended anyway... > >> MH> Let's do a Fedora change? Coordinate with FPC? > >> > >> We (FPC) have talked about this before but I don't think it's really up > >> to FPC. The change process isn't really the right way to do it, either, > >> since this is really a policy revision. I just think FESCo needs to > >> decide whether or not it would like to relax the policy, and if so, how. > >> > >> Here are the relevant points as I see them (unless I'm forgetting > >> something): > >> > >> * dnf system-upgrade generally handles versions going backward without > >> issue. The specific case of epoch being reset is not an issue. > >> > >> * dnf upgrade would not handle this, causing problems for those running > >> rawhide or using unsupported methods of upgrading between releases. > >> > >> * Those running rawhide would have to run distro-sync in order to > >> upgrade (which would of course reset any locally built updated > >> packages and such). They would have to do this every time any > >> installed package drops epoch. > >> > >> * Those using an unsupported method of upgrading would need to > >> incorporate distro-sync. > >> > >> * Dropping epoch outside of rawhide would generally be bad. > >> > >> * Koji and the compose process do handle things "going backwards", as > >> this has happened multiple times in the past without things dying. > >> What's important there is which version was most recently tagged. > >> > >> * Bodhi shouldn't be involved here as this would be restricted to > >> rawhide. > >> > >> Personally I'm in support of relaxing the restriction in some form, but > >> I prefer a single "drop Epoch: day" where epochs in rawhide are > >> _automatically_ removed and the packages rebuilt. This gives a single > >> point in time where rawhide users need to do a distro-sync in order to > >> properly track updates. Allowing epochs to be dropped without > >> coordination seems to me to be a burden on rawhide users, but I don't > >> think a single flag day would be problematic. > >> > >> I would expect the first flag day to be busy. I see 756 Epoch: tags > >> currently, though 161 are set to 0 for whatever reason. Afterwards I > >> would expect no more than a small number of packages per cycle to > >> acquire Epoch: tags. > >> > >> - J< > > > > If DNF were helpful and was able to report packages, which has higher > > NVR then E(NVR), > > > I meant (E)NVR actually. > > > V. > > > > then I can imagine that reset of epoch could work. > > Otherwise I am against resetting epochs. > > I'm confused, why would that matter? And DNF always reports NEVRA... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
Dne 09. 03. 19 v 13:00 Vít Ondruch napsal(a): > Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a): >>> "MH" == Miro Hrončok writes: >> MH> On 08. 03. 19 21:16, Neal Gompa wrote: I really wish we'd allow Epochs to be reset on distribution upgrades. With dnf distro-sync (which is used by system-upgrade) Epochs don't really matter and upgrades work as intended anyway... >> MH> Let's do a Fedora change? Coordinate with FPC? >> >> We (FPC) have talked about this before but I don't think it's really up >> to FPC. The change process isn't really the right way to do it, either, >> since this is really a policy revision. I just think FESCo needs to >> decide whether or not it would like to relax the policy, and if so, how. >> >> Here are the relevant points as I see them (unless I'm forgetting >> something): >> >> * dnf system-upgrade generally handles versions going backward without >> issue. The specific case of epoch being reset is not an issue. >> >> * dnf upgrade would not handle this, causing problems for those running >> rawhide or using unsupported methods of upgrading between releases. >> >> * Those running rawhide would have to run distro-sync in order to >> upgrade (which would of course reset any locally built updated >> packages and such). They would have to do this every time any >> installed package drops epoch. >> >> * Those using an unsupported method of upgrading would need to >> incorporate distro-sync. >> >> * Dropping epoch outside of rawhide would generally be bad. >> >> * Koji and the compose process do handle things "going backwards", as >> this has happened multiple times in the past without things dying. >> What's important there is which version was most recently tagged. >> >> * Bodhi shouldn't be involved here as this would be restricted to >> rawhide. >> >> Personally I'm in support of relaxing the restriction in some form, but >> I prefer a single "drop Epoch: day" where epochs in rawhide are >> _automatically_ removed and the packages rebuilt. This gives a single >> point in time where rawhide users need to do a distro-sync in order to >> properly track updates. Allowing epochs to be dropped without >> coordination seems to me to be a burden on rawhide users, but I don't >> think a single flag day would be problematic. >> >> I would expect the first flag day to be busy. I see 756 Epoch: tags >> currently, though 161 are set to 0 for whatever reason. Afterwards I >> would expect no more than a small number of packages per cycle to >> acquire Epoch: tags. >> >> - J< > > If DNF were helpful and was able to report packages, which has higher > NVR then E(NVR), I meant (E)NVR actually. V. > then I can imagine that reset of epoch could work. > Otherwise I am against resetting epochs. > > > Vít > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a): >> "MH" == Miro Hrončok writes: > MH> On 08. 03. 19 21:16, Neal Gompa wrote: >>> I really wish we'd allow Epochs to be reset on distribution upgrades. >>> With dnf distro-sync (which is used by system-upgrade) Epochs don't >>> really matter and upgrades work as intended anyway... > MH> Let's do a Fedora change? Coordinate with FPC? > > We (FPC) have talked about this before but I don't think it's really up > to FPC. The change process isn't really the right way to do it, either, > since this is really a policy revision. I just think FESCo needs to > decide whether or not it would like to relax the policy, and if so, how. > > Here are the relevant points as I see them (unless I'm forgetting > something): > > * dnf system-upgrade generally handles versions going backward without > issue. The specific case of epoch being reset is not an issue. > > * dnf upgrade would not handle this, causing problems for those running > rawhide or using unsupported methods of upgrading between releases. > > * Those running rawhide would have to run distro-sync in order to > upgrade (which would of course reset any locally built updated > packages and such). They would have to do this every time any > installed package drops epoch. > > * Those using an unsupported method of upgrading would need to > incorporate distro-sync. > > * Dropping epoch outside of rawhide would generally be bad. > > * Koji and the compose process do handle things "going backwards", as > this has happened multiple times in the past without things dying. > What's important there is which version was most recently tagged. > > * Bodhi shouldn't be involved here as this would be restricted to > rawhide. > > Personally I'm in support of relaxing the restriction in some form, but > I prefer a single "drop Epoch: day" where epochs in rawhide are > _automatically_ removed and the packages rebuilt. This gives a single > point in time where rawhide users need to do a distro-sync in order to > properly track updates. Allowing epochs to be dropped without > coordination seems to me to be a burden on rawhide users, but I don't > think a single flag day would be problematic. > > I would expect the first flag day to be busy. I see 756 Epoch: tags > currently, though 161 are set to 0 for whatever reason. Afterwards I > would expect no more than a small number of packages per cycle to > acquire Epoch: tags. > > - J< If DNF were helpful and was able to report packages, which has higher NVR then E(NVR), then I can imagine that reset of epoch could work. Otherwise I am against resetting epochs. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
On 08. 03. 19 23:19, Jason L Tibbitts III wrote: "MH" == Miro Hrončok writes: MH> On 08. 03. 19 21:16, Neal Gompa wrote: I really wish we'd allow Epochs to be reset on distribution upgrades. With dnf distro-sync (which is used by system-upgrade) Epochs don't really matter and upgrades work as intended anyway... MH> Let's do a Fedora change? Coordinate with FPC? We (FPC) have talked about this before but I don't think it's really up to FPC. The change process isn't really the right way to do it, either, since this is really a policy revision. I just think FESCo needs to decide whether or not it would like to relax the policy, and if so, how. Here are the relevant points as I see them (unless I'm forgetting something): * dnf system-upgrade generally handles versions going backward without issue. The specific case of epoch being reset is not an issue. * dnf upgrade would not handle this, causing problems for those running rawhide or using unsupported methods of upgrading between releases. * Those running rawhide would have to run distro-sync in order to upgrade (which would of course reset any locally built updated packages and such). They would have to do this every time any installed package drops epoch. * Those using an unsupported method of upgrading would need to incorporate distro-sync. * Dropping epoch outside of rawhide would generally be bad. * Koji and the compose process do handle things "going backwards", as this has happened multiple times in the past without things dying. What's important there is which version was most recently tagged. * Bodhi shouldn't be involved here as this would be restricted to rawhide. Personally I'm in support of relaxing the restriction in some form, but I prefer a single "drop Epoch: day" where epochs in rawhide are _automatically_ removed and the packages rebuilt. This gives a single point in time where rawhide users need to do a distro-sync in order to properly track updates. Allowing epochs to be dropped without coordination seems to me to be a burden on rawhide users, but I don't think a single flag day would be problematic. I would expect the first flag day to be busy. I see 756 Epoch: tags currently, though 161 are set to 0 for whatever reason. Afterwards I would expect no more than a small number of packages per cycle to acquire Epoch: tags. One thing to consider here is other packages that have Requires etc. on something like "foo > 1:1.2", so if it is automated, this part needs to be automated as well. If we do this, we might have a "flag day" but not automated for all 756 packages, but opt in. Aka we create a window on rawhide, and packagers would sign up for this, we announce the window, let them do it, and we close the window... ? This needs a lot of consideration for sure, but I think it can be done somehow. However I'm not sure it's worth the effort. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
> "MH" == Miro Hrončok writes: MH> On 08. 03. 19 21:16, Neal Gompa wrote: >> I really wish we'd allow Epochs to be reset on distribution upgrades. >> With dnf distro-sync (which is used by system-upgrade) Epochs don't >> really matter and upgrades work as intended anyway... MH> Let's do a Fedora change? Coordinate with FPC? We (FPC) have talked about this before but I don't think it's really up to FPC. The change process isn't really the right way to do it, either, since this is really a policy revision. I just think FESCo needs to decide whether or not it would like to relax the policy, and if so, how. Here are the relevant points as I see them (unless I'm forgetting something): * dnf system-upgrade generally handles versions going backward without issue. The specific case of epoch being reset is not an issue. * dnf upgrade would not handle this, causing problems for those running rawhide or using unsupported methods of upgrading between releases. * Those running rawhide would have to run distro-sync in order to upgrade (which would of course reset any locally built updated packages and such). They would have to do this every time any installed package drops epoch. * Those using an unsupported method of upgrading would need to incorporate distro-sync. * Dropping epoch outside of rawhide would generally be bad. * Koji and the compose process do handle things "going backwards", as this has happened multiple times in the past without things dying. What's important there is which version was most recently tagged. * Bodhi shouldn't be involved here as this would be restricted to rawhide. Personally I'm in support of relaxing the restriction in some form, but I prefer a single "drop Epoch: day" where epochs in rawhide are _automatically_ removed and the packages rebuilt. This gives a single point in time where rawhide users need to do a distro-sync in order to properly track updates. Allowing epochs to be dropped without coordination seems to me to be a burden on rawhide users, but I don't think a single flag day would be problematic. I would expect the first flag day to be busy. I see 756 Epoch: tags currently, though 161 are set to 0 for whatever reason. Afterwards I would expect no more than a small number of packages per cycle to acquire Epoch: tags. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
