[EPEL-devel] Re: Fast-moving packages in EPEL
On 14.10.20 19:32, Kevin Fenzi wrote: > We now allow scls if: > > * They only need to be used at build time (ie, the rpms produced do not > require users to install/enable any scls) > * They are approved by the epel steering comittee. > > So far we have only enabled devtoolset. (so for example, chromium uses > devtoolset to build with a newer gcc, but does not require users to > install or enable anything to use it). > > In the case of php, this would likely not work because it would require > users to install/enable php to get the webserver module or cmd line. Thanks for the clarification, but you're right, that won't help here, as NC has extensive runtime PHP7.2+ dependencies. Christopher ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
On Tue, Oct 13, 2020 at 12:14:24PM +0200, Leon Fauster wrote: > Am 13.10.20 um 10:12 schrieb Christopher Engelhard: > > On 12.10.20 10:49, Leon Fauster wrote: > > > Not sure but IIRC EPEL should not depend on software collections ...? > > > > Can someone confirm that? If the package can't depend on php7.2+, then > > the question of how to deal with EPEL7 is moot. > > > > My recall was this > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/DBAQB3V35TXPNUV4UKKHXUC52BENZJUQ/ It's changed a bit since then. We now allow scls if: * They only need to be used at build time (ie, the rpms produced do not require users to install/enable any scls) * They are approved by the epel steering comittee. So far we have only enabled devtoolset. (so for example, chromium uses devtoolset to build with a newer gcc, but does not require users to install or enable anything to use it). In the case of php, this would likely not work because it would require users to install/enable php to get the webserver module or cmd line. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
On 13.10.20 12:14, Leon Fauster wrote: > My recall was this > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/DBAQB3V35TXPNUV4UKKHXUC52BENZJUQ/ OK, thanks, that clears that up. So I'll go ahead and retire the EPEL7 package. Maybe I can put an updated one on Copr instead. Thanks to all of you, you helped tremendously. Christopher ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
Am 13.10.20 um 10:12 schrieb Christopher Engelhard: On 12.10.20 10:49, Leon Fauster wrote: Not sure but IIRC EPEL should not depend on software collections ...? Can someone confirm that? If the package can't depend on php7.2+, then the question of how to deal with EPEL7 is moot. My recall was this https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/DBAQB3V35TXPNUV4UKKHXUC52BENZJUQ/ -- Leon ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
On 12.10.20 10:49, Leon Fauster wrote: > Not sure but IIRC EPEL should not depend on software collections ...? Can someone confirm that? If the package can't depend on php7.2+, then the question of how to deal with EPEL7 is moot. Christopher ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
On 12.10.20 12:09, Petr Pisar wrote: > RHEL releases a minor version every six months. And as I remember, EPEL8 > allows breaking upgrades at each new RHEL release. Thus technically, it's > possible to rebase the package every year without getting into conflict with > packaging guidelines. On the other hand, I'm not sure whether the users know > it and expect it. OK, that might work - somehow I remembered the minor versions being released more rarely. > You could package each new incompatible version into a separate module stream > and keep maintaining only the latest one. This way the users could switch > to the newer stream whenever they feel comfortable. If they slip switching > to the latest stream, then can migrate any later by hopping through all the > intermediary streams up to the latest one. That could be even automated by > a script. At As Nick Howitt pointed out, NC can be modified to skip the version check, so maybe the hopping isn't even necessary. Still, if the old streams remain available ... intriguing possibilities. > > There is a downside of the modules: There is no mechanism for tracking the > latest stream automatically. DNF team is willing to implement the mechanism, > but so far it's only a conception. It's also dubious whether the new mechanism > would be ported back to RHEL 8. So far users have to switch the streams > manually. I was thinking of offering a nextcloud-stable or -latest stream that simply follows upstream release channel (i.e. N+1.0 replaces N.x, even if N is still supported and receiving updates) in addition tonextcloud-. Or have a normal (ursine?) package for that. That way users can choose between an automatically updating or version-stable Nextcloud, and whatever they choose, they know what they're in for. Christopher ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
Am 11.10.20 um 23:29 schrieb Nick Howitt: On 11/10/2020 18:22, Christopher Engelhard wrote: On 11.10.20 15:10, H wrote: I'd like it updated, and kept updated, for EPEL 7. Do you happen to have a system with the current 10.0.something EPEL7 package set up & would you be willing to - if I make an updated package - test the upgrade process? I could set up something myself, but I think most problems are going to be with database changes, and that's not really testable on an empty test install ... How do you intend to handle the switch to PHP7.3? It is not safe to force installations to go from 5.4 to 7.3, but you can use the rh-php73-php-fpm service but you heed to change the nextcloud httpd configlet. Not so nice is that rh-php70-php-fpm, rh-php71-php-fpm, rh-php72-php-fpm and rh-php73-php-fpm all use the same listening port, 9000. Not sure but IIRC EPEL should not depend on software collections ...? -- Leon ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
On Sun, Oct 11, 2020 at 02:18:26PM +0200, Christopher Engelhard wrote: > One thing I forgot that makes things even worse: > > - upstream does not support updates across more than one major version, > so anybody who actually has the old v10 installed will have their > installation completely broken by ANY update at this point > - for the same reason, trying to limit major updates to whenever > CentOS/RHEL release a new version won't work either. > RHEL releases a minor version every six months. And as I remember, EPEL8 allows breaking upgrades at each new RHEL release. Thus technically, it's possible to rebase the package every year without getting into conflict with packaging guidelines. On the other hand, I'm not sure whether the users know it and expect it. > I think I'll retire and look into re-adding it via modularity. > You could package each new incompatible version into a separate module stream and keep maintaining only the latest one. This way the users could switch to the newer stream whenever they feel comfortable. If they slip switching to the latest stream, then can migrate any later by hopping through all the intermediary streams up to the latest one. That could be even automated by a script. There is a downside of the modules: There is no mechanism for tracking the latest stream automatically. DNF team is willing to implement the mechanism, but so far it's only a conception. It's also dubious whether the new mechanism would be ported back to RHEL 8. So far users have to switch the streams manually. -- Petr signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
On 11.10.20 23:29, Nick Howitt wrote: > How do you intend to handle the switch to PHP7.3? Not sure yet - I wanted to make sure it even makes sense to keep nextcloud in EPEL7 first. But that's another reason it's probably risky to jump people from NC10 to NC18+ (NC13 was the last release to support PHP5.x, so that's no use). Maybe Copr is the way to go here, people will definitely only get the package if they seek it out, and it's easier to leave instructions/caveats where people will see them. My current plan is - put current nextcloud, following their 'stable' path in epel-8-playground - see about creating nextcloud-XX and maybe nextcloud-latest modules for inclusion in epel8 - epel7: ??? Christopher ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
On 11/10/2020 18:22, Christopher Engelhard wrote: On 11.10.20 15:10, H wrote: I'd like it updated, and kept updated, for EPEL 7. Do you happen to have a system with the current 10.0.something EPEL7 package set up & would you be willing to - if I make an updated package - test the upgrade process? I could set up something myself, but I think most problems are going to be with database changes, and that's not really testable on an empty test install ... How do you intend to handle the switch to PHP7.3? It is not safe to force installations to go from 5.4 to 7.3, but you can use the rh-php73-php-fpm service but you heed to change the nextcloud httpd configlet. Not so nice is that rh-php70-php-fpm, rh-php71-php-fpm, rh-php72-php-fpm and rh-php73-php-fpm all use the same listening port, 9000. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
On 11.10.20 15:10, H wrote: > I'd like it updated, and kept updated, for EPEL 7. Do you happen to have a system with the current 10.0.something EPEL7 package set up & would you be willing to - if I make an updated package - test the upgrade process? I could set up something myself, but I think most problems are going to be with database changes, and that's not really testable on an empty test install ... Christopher ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
On Sun, Oct 11, 2020 at 07:47:22AM +0200, Christopher Engelhard wrote: > Hi, > the nextcloud server package is currently stuck at ancient version 10 > (current is 20) in EPEL7 (It's not (yet) available EPEL8 repos). > > I'd like to fix that, but > > - upstream releases a new version roughly every 4 months > - they support them only for roughly 1 year (officially it's "at least 8 > months") > - nextcloud receives A LOT of bug- and CVE-fixes, and there is no way > I'll be able to backport all of those, so staying on an older version > after upstream stopped support is not really an option. > > So, should this still be in EPEL even though it would receive major > version updates or is it better to retire it from EPEL? > > I suspect that EPEL users would probably prefer to run it from > upstream's containers anyways, so retiring might make more sense, but > I'm open either way. There's a number of options: * Keep in epel - As you note though this is major upgrades and it's not something people expect. * It doesn't help you any with epel7, but for 8 you could put it in epel8-playground. There's much more expectation of packages that have major upgrades and change things, so people who consume it might be fine with that. * You could try a module (again does not help with epel7). This should work except if you need any non default modules. * You could just put it in a copr (this would work for both epel7 and epel8). It's not as discoverable there, but this might be a good solution. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
On Sun, Oct 11, 2020 at 02:05:20PM +0200, Christopher Engelhard wrote: > I'm sort of hesitant to dive into learning how modularity works, though > ... although, maybe a good opportunity to learn. The spin-up is a little rougher than we'd hoped, but once you've got it set up it shouldn't be too much extra work. This does seem like a good use case for it! -- Matthew Miller Fedora Project Leader ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
On October 11, 2020 7:57:45 AM EDT, Nicolas Chauvet wrote: >Le dim. 11 oct. 2020 à 07:47, Christopher Engelhard a >écrit : >> >> Hi, >> the nextcloud server package is currently stuck at ancient version 10 >> (current is 20) in EPEL7 (It's not (yet) available EPEL8 repos). >> >> I'd like to fix that, but >> >> - upstream releases a new version roughly every 4 months >> - they support them only for roughly 1 year (officially it's "at >least 8 >> months") >> - nextcloud receives A LOT of bug- and CVE-fixes, and there is no way >> I'll be able to backport all of those, so staying on an older version >> after upstream stopped support is not really an option. >> >> So, should this still be in EPEL even though it would receive major >> version updates or is it better to retire it from EPEL? >> >> I suspect that EPEL users would probably prefer to run it from >> upstream's containers anyways, so retiring might make more sense, but >> I'm open either way. >I'm fine with retiring it. > >But on the alternatives , you can have modules (or application >streams) for both epel and fedora. >It would be a good way forward. so it won't enforce nextcloud version >with a given fedora and or epel and would allow to update nextcloud at >users own pace. > >But as epel7 is concerned, I'm good for retirement. >___ >epel-devel mailing list -- epel-devel@lists.fedoraproject.org >To unsubscribe send an email to >epel-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/epel-devel@lists.fedoraproject.org I'd like it updated, and kept updated, for EPEL 7. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
The version check can be disabled in NC:
diff -Naur -b nextcloud/lib/private/Updater.php
nextcloud.njh/lib/private/Updater.php
--- nextcloud/lib/private/Updater.php 2019-04-08 15:22:33.0 -0600
+++ nextcloud.tjr/lib/private/Updater.php 2019-05-20 12:48:46.007165729
-0600
@@ -188,14 +188,11 @@
}
if ($currentVendor === 'nextcloud') {
- return
isset($allowedPreviousVersions[$currentVendor][$majorMinor])
- && (version_compare($oldVersion, $newVersion,
'<=') ||
- $this->config->getSystemValue('debug',
false));
+ return true;
}
// Check if the instance can be migrated
- return
isset($allowedPreviousVersions[$currentVendor][$majorMinor]) ||
-
isset($allowedPreviousVersions[$currentVendor][$oldVersion]);
+ return true;
}
/**
It has been used successfully to jump versions, but jumping 10 versions
is a bit more dramatic.
It is also worth pointing out that to run NC20 you need PHP7.3. I think
19 needs 7.1 or 7.2 and so on. It is possible to use the SIG PHP 7.3.
Nick
On 11/10/2020 13:18, Christopher Engelhard wrote:
One thing I forgot that makes things even worse:
- upstream does not support updates across more than one major version,
so anybody who actually has the old v10 installed will have their
installation completely broken by ANY update at this point
- for the same reason, trying to limit major updates to whenever
CentOS/RHEL release a new version won't work either.
I think I'll retire and look into re-adding it via modularity.
Christopher
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
One thing I forgot that makes things even worse: - upstream does not support updates across more than one major version, so anybody who actually has the old v10 installed will have their installation completely broken by ANY update at this point - for the same reason, trying to limit major updates to whenever CentOS/RHEL release a new version won't work either. I think I'll retire and look into re-adding it via modularity. Christopher ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
On 11.10.20 13:57, Nicolas Chauvet wrote: > I'm fine with retiring it. > > But on the alternatives , you can have modules (or application > streams) for both epel and fedora. > It would be a good way forward. so it won't enforce nextcloud version > with a given fedora and or epel and would allow to update nextcloud at > users own pace. I'm sort of hesitant to dive into learning how modularity works, though ... although, maybe a good opportunity to learn. Christopher ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fast-moving packages in EPEL
Le dim. 11 oct. 2020 à 07:47, Christopher Engelhard a écrit : > > Hi, > the nextcloud server package is currently stuck at ancient version 10 > (current is 20) in EPEL7 (It's not (yet) available EPEL8 repos). > > I'd like to fix that, but > > - upstream releases a new version roughly every 4 months > - they support them only for roughly 1 year (officially it's "at least 8 > months") > - nextcloud receives A LOT of bug- and CVE-fixes, and there is no way > I'll be able to backport all of those, so staying on an older version > after upstream stopped support is not really an option. > > So, should this still be in EPEL even though it would receive major > version updates or is it better to retire it from EPEL? > > I suspect that EPEL users would probably prefer to run it from > upstream's containers anyways, so retiring might make more sense, but > I'm open either way. I'm fine with retiring it. But on the alternatives , you can have modules (or application streams) for both epel and fedora. It would be a good way forward. so it won't enforce nextcloud version with a given fedora and or epel and would allow to update nextcloud at users own pace. But as epel7 is concerned, I'm good for retirement. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
