Plan to delete vagrant & Virtualization:vagrant by the end of November
Dear all,
due to Hashicorp changing the license of vagrant to the BUSL, we can no
longer update vagrant in openSUSE. I don't have the cycles to maintain
vagrant myself indefinitely and plan to send a delete request at the end
of November to Factory. Once that goes in, I also plan to remove the
Virtualization:vagrant project to reduce the number of rubygems we have
in openSUSE.
If you don't like this plan and decide to scream at me, please scream an
actionable plan that involves you :-)
Cheers,
Dan
--
Dan Čermák
On Fri, Nov 3, 2023 at 6:07 AM Dan Čermák via openSUSE Factory
Dear all,
due to Hashicorp changing the license of vagrant to the BUSL, we can no longer update vagrant in openSUSE. I don't have the cycles to maintain vagrant myself indefinitely and plan to send a delete request at the end of November to Factory. Once that goes in, I also plan to remove the Virtualization:vagrant project to reduce the number of rubygems we have in openSUSE.
If you don't like this plan and decide to scream at me, please scream an actionable plan that involves you :-)
There appears to be an active fork of Vagrant now? https://github.com/viagrunts/viagrunts Would that work as a new target? -- 真実はいつも一つ！/ Always, there's only one truth!
There appears to be an active fork of Vagrant now? https://github.com/viagrunts/viagrunts
Would that work as a new target?
Really? That thing where noone knows who the maintainers are, and these maintainers don't even know how to spell their own project (three different spellings in the README alone)? No, please don't replace a package with such a random untrustworthy source. -nik
Hi Dominik,
Dominik George via openSUSE Factory
There appears to be an active fork of Vagrant now? https://github.com/viagrunts/viagrunts
Would that work as a new target?
Really? That thing where noone knows who the maintainers are, and these maintainers don't even know how to spell their own project (three different spellings in the README alone)?
No, please don't replace a package with such a random untrustworthy source.
Don't worry, I will most certainly not start maintaining a random fork
to replace vagrant.
As I wrote in my original email, I will execute the deletion by the end
of this months, unless someone steps up to either maintain vagrant or a
fork of it. But I will not do this myself.
Cheers,
Dan
--
Dan Čermák
On Fri, 2023-11-03 at 11:07 +0100, Dan Čermák via openSUSE Factory wrote:
Dear all,
due to Hashicorp changing the license of vagrant to the BUSL, we can no longer update vagrant in openSUSE. I don't have the cycles to maintain vagrant myself indefinitely and plan to send a delete request at the end of November to Factory. Once that goes in, I also plan to remove the Virtualization:vagrant project to reduce the number of rubygems we have in openSUSE.
If you don't like this plan and decide to scream at me, please scream an actionable plan that involves you :-)
I like thet plan - BUT please first disarm the openQA tests for vagrant. If we're already planning on dropping it, we should stop testing it at least beforehand. This can happen at any moment before the delete requests come in (once tests are gone, vagrant can also be removed from Ring1 imho) Cheers, Dominique
Hi Dominique,
Dominique Leuenberger
On Fri, 2023-11-03 at 11:07 +0100, Dan Čermák via openSUSE Factory wrote:
Dear all,
due to Hashicorp changing the license of vagrant to the BUSL, we can no longer update vagrant in openSUSE. I don't have the cycles to maintain vagrant myself indefinitely and plan to send a delete request at the end of November to Factory. Once that goes in, I also plan to remove the Virtualization:vagrant project to reduce the number of rubygems we have in openSUSE.
If you don't like this plan and decide to scream at me, please scream an actionable plan that involves you :-)
I like thet plan - BUT please first disarm the openQA tests for vagrant. If we're already planning on dropping it, we should stop testing it at least beforehand.
This actually brings up another issue, we use vagrant to test our
opensuse vagrant boxes. But without vagrant in the distro, we'll have a
hard time testing the boxes. The only simple way that I see is to
install vagrant from the upstream provided binary:
https://developer.hashicorp.com/vagrant/install?product_intent=vagrant
Cheers,
Dan
--
Dan Čermák
On Fri, 2023-11-03 at 11:07 +0100, Dan Čermák via openSUSE Factory wrote:
Dear all,
due to Hashicorp changing the license of vagrant to the BUSL, we can no longer update vagrant in openSUSE. I don't have the cycles to maintain vagrant myself indefinitely and plan to send a delete request at the end of November to Factory. Once that goes in, I also plan to remove the Virtualization:vagrant project to reduce the number of rubygems we have in openSUSE.
If you don't like this plan and decide to scream at me, please scream an actionable plan that involves you :-)
I won't scream, but I can't quite understand why the project and the TW package have to be deleted so quickly. Can't we just freeze the current package and keep it for some time? We are keeping old vagrant versions around in Leap repositories, are they going to be removed as well? Hashicorp has announced that "Security fixes will be backported under MPL 2.0 through December 31, 2023", but the package doesn't seem to have a history of many CVE fixes (current changelog mentions only one, from 2020). I can see that having it in the official repo may be problematic if you step back as maintainer and nobody else volunteers. But we should be able to provide an installable TW package in some OBS project. Otherwise, people who depend on vagrant will be forced to download the binary from hashicorp. I strongly doubt that they'll be better off with that than using a 2.3.7 package from OBS. Sure, the day will come when some dependencies can't be satisfied any more, and vagrant will simply cease to work. But that day isn't near yet. Until then, we could add a BIG FAT WARNING to the package telling users that it's frozen. Regards Martin
Hi Martin,
Martin Wilck
On Fri, 2023-11-03 at 11:07 +0100, Dan Čermák via openSUSE Factory wrote:
Dear all,
due to Hashicorp changing the license of vagrant to the BUSL, we can no longer update vagrant in openSUSE. I don't have the cycles to maintain vagrant myself indefinitely and plan to send a delete request at the end of November to Factory. Once that goes in, I also plan to remove the Virtualization:vagrant project to reduce the number of rubygems we have in openSUSE.
If you don't like this plan and decide to scream at me, please scream an actionable plan that involves you :-)
I won't scream, but I can't quite understand why the project and the TW package have to be deleted so quickly. Can't we just freeze the current package and keep it for some time? We are keeping old vagrant versions around in Leap repositories, are they going to be removed as well?
Hashicorp has announced that "Security fixes will be backported under MPL 2.0 through December 31, 2023", but the package doesn't seem to have a history of many CVE fixes (current changelog mentions only one, from 2020).
I can see that having it in the official repo may be problematic if you step back as maintainer and nobody else volunteers. But we should be able to provide an installable TW package in some OBS project.
Otherwise, people who depend on vagrant will be forced to download the binary from hashicorp. I strongly doubt that they'll be better off with that than using a 2.3.7 package from OBS. Sure, the day will come when some dependencies can't be satisfied any more, and vagrant will simply cease to work. But that day isn't near yet. Until then, we could add a BIG FAT WARNING to the package telling users that it's frozen.
This is mostly for practical reasons. We wish to cleanup the Tumbleweed
Ruby gems (in devel:languages:ruby:extensions) as there is a huge amount
of old, unmaintained, fbfs or uninstallable gems. A non-trivial subset
of these is dragged in by vagrant. By deleting vagrant, we can cleanup
the gems more aggressively reducing the maintenance effort.
Cheers,
Dan
--
Dan Čermák
On Wed, 2023-11-15 at 18:25 +0100, Dan Čermák wrote:
This is mostly for practical reasons. We wish to cleanup the Tumbleweed Ruby gems (in devel:languages:ruby:extensions) as there is a huge amount of old, unmaintained, fbfs or uninstallable gems. A non-trivial subset of these is dragged in by vagrant. By deleting vagrant, we can cleanup the gems more aggressively reducing the maintenance effort.
Any chance to simply migrate the respective gems to Virtualization:vagrant? Martin
Martin Wilck
On Wed, 2023-11-15 at 18:25 +0100, Dan Čermák wrote:
This is mostly for practical reasons. We wish to cleanup the Tumbleweed Ruby gems (in devel:languages:ruby:extensions) as there is a huge amount of old, unmaintained, fbfs or uninstallable gems. A non-trivial subset of these is dragged in by vagrant. By deleting vagrant, we can cleanup the gems more aggressively reducing the maintenance effort.
Any chance to simply migrate the respective gems to Virtualization:vagrant?
It could be done, but it would require to convert *every* gem into a
versioned one (except for those that are obviously dead upstream and
unlikely to ever receive updates). Otherwise the next rubygem update to
Factory will cause package conflicts and render vagrant uninstallable.
To be frankly honest, that is just too much work for me to invest into a
project that is dead anyway. If anyone wants to do it, I'll gladly give
you the rights to do so.
Cheers,
Dan
--
Dan Čermák
1 If it's not too late, I can try to take over meintainer duties. I don't know how the ruby infrastructure works and I can't say for sure that I can handle it, but I can try. 2 Dan on the exact list of ruby extensions that can be gotten rid of by uninstalling vagrant. It may turn out that it is not a very large number. 3 I don't think it's a good idea to remove vagrant while it's still built and running while Factory has ruby 3.2 and while it's not yet clear about its fork.
Илья Индиго via openSUSE Factory
1 If it's not too late, I can try to take over meintainer duties. I don't know how the ruby infrastructure works and I can't say for sure that I can handle it, but I can try.
The delete request in Factory has not been accepted yet. You can still file a request for maintainership and take it over (and also vagrant-libvirt, that one is on the removal list too).
2 Dan on the exact list of ruby extensions that can be gotten rid of by uninstalling vagrant. It may turn out that it is not a very large number.
It is a non-trivial number, as it includes not only the direct dependencies but also transitive ones and the whole dependency tree of vagrant-libvirt.
3 I don't think it's a good idea to remove vagrant while it's still built and running while Factory has ruby 3.2 and while it's not yet clear about its fork.
You are free to prove me otherwise :-)
Cheers,
Dan
--
Dan Čermák
My plan of action is to maintain 2.3.7 as long as possible and look at forks, if they are compatible and stable enough I will switch to some fork. If I fail or no longer have a need for vagrant, I will repeat this removal process.
participants (6)
-
Dan Čermák -
Dominik George -
Dominique Leuenberger -
Martin Wilck -
Neal Gompa -
Илья Индиго