Re: Please test Vagrant 1.9.1
Dne 15.2.2017 v 16:39 Colin Walters napsal(a):
> On Wed, Feb 15, 2017, at 10:07 AM, Vít Ondruch wrote:
>
>> First of all, I am still not fond of moving the plugins.json into /usr.
> Why is that? It's like the fontconfig one, which was discussed in FESCo:
> https://pagure.io/fesco/issue/1635#comment-51133
> and approved:
> https://pagure.io/fesco/issue/1635#comment-67306
Thinking about it back and forth, discussed it again with some
colleagues, considering Matt's comment [1], I'm going to change my mind.
But speaking about fontconfig, the situation for Vagrant is way
different. As far as I understand, fontconfig can run without that
caches and you can regenerated them. While Vagrant can't find its
plugins without the plugins.json file and there is no easy (or upstream
supported) way how to regenerated that file.
>> So from now, I keep Vagrant to look for the plugins.json on the
>> place, where Vagrant expects it, i.e. at
>> /usr/share/vagrant/plugins.json, but this is link to
>> /var/lib/vagrant/plugins.json.
> Why not just keep it in /usr if that's where upstream already
> expects it?
I would be wary mentioning upstream in this context, since Vagrant
upstream supports only usage of their RPM. In their RPM, the file is on
different location (/opt/) and it is completely static as far as I
can say and nobody is supposed to touch it.
The difference is that upstream ships with predefined set of plugins and
all the other plugins are installed into user $HOME. We distribute
plugins packaged in Fedora, install the into system location and
therefore we have to update plugins.json to make Vagrant aware about them.
>> Basically, if I understand correctly, the %post is not executed by
>> rpm-ostree.
> rpm-ostree *does* execute %post.
Not sure where I got this. I probably somehow wrongly got the
documentation [2] or may be I confused it with %preun [3]? Anyway it is
not very clear to me what rpm-ostree is actually doing considering
tweaks like [4] (I know, you want to get rid of them ...).
> We actually don't use librpm
> for this, but custom code for a few reasons. We want to have updates
> applied *offline* by default into a new root, so we don't want e.g.
> `systemctl restart foo`
> to run. We currently run every %post in a bubblewrap-based container
> with ostree's rofiles-fuse.
> https://bugzilla.redhat.com/show_bug.cgi?id=1352154
Thx for explanation.
>> In this case, the /usr/share/vagrant/plugins.json neither
>> the link to /var/lib/vagrant/plugins.json is created, which should be
>> fine for Vagrant. As soon as some Vagrant plugin is installed, the
>> %transfiletriggerin kicks in and when the file/link is not present, it
>> just creates the /usr/share/vagrant/plugins.json.
> rpm-ostree doesn't execute %transfiletriggerin though. We can look
> at that, though if vagrant has a %posttrans that regenerated the index,
> that'd work in both cases.
%transfiletrigger{in,un} are essential for plugin registration. Actually
I'd prefer to use %filetrigger{in,un}, but they are not correctly
implemented ATM [5].
No simple way to use %posttrans, since there is not easily possible to
rebuild the plugins.json from scratch. Hence the scriptlets just
add/remove the plugins which are installed/uninstalled.
>
>
>> This way, for normal
>> Fedora, the plugin.json would be kept in /var/lib/vagrant/plugins.json
>> with symlink to /usr/share/vagrant/plugins.json while for rpm-ostree,
>> the /usr/share/vagrant/plugins.json would be regular and the only file.
> If that's the end result, that seems sane to me. Though I don't quite
> understand why not just move it to /usr unconditionally, like fontconfig.
Actually, I tried that but I must postpone this change due to backward
compatibility with current vagrant plugins, otherwise the scriptlets
would break :/ So this might change in F28-F29 timeframe unless some
other incompatibility pops up.
>
>> Does this work for you? Can you test the latest Copr build [3]?
> Yeah, I probably can in a bit.
Thx
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1377367#c12
[2] https://ostree.readthedocs.io/en/latest/manual/adapting-existing/
[3] https://github.com/projectatomic/rpm-ostree/pull/338
[4] https://github.com/projectatomic/rpm-ostree/pull/364
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1301677#c4
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please test Vagrant 1.9.1
On Wed, Feb 15, 2017, at 10:07 AM, Vít Ondruch wrote: > First of all, I am still not fond of moving the plugins.json into /usr. Why is that? It's like the fontconfig one, which was discussed in FESCo: https://pagure.io/fesco/issue/1635#comment-51133 and approved: https://pagure.io/fesco/issue/1635#comment-67306 > So from now, I keep Vagrant to look for the plugins.json on the > place, where Vagrant expects it, i.e. at > /usr/share/vagrant/plugins.json, but this is link to > /var/lib/vagrant/plugins.json. Why not just keep it in /usr if that's where upstream already expects it? > Basically, if I understand correctly, the %post is not executed by > rpm-ostree. rpm-ostree *does* execute %post. We actually don't use librpm for this, but custom code for a few reasons. We want to have updates applied *offline* by default into a new root, so we don't want e.g. `systemctl restart foo` to run. We currently run every %post in a bubblewrap-based container with ostree's rofiles-fuse. https://bugzilla.redhat.com/show_bug.cgi?id=1352154 > In this case, the /usr/share/vagrant/plugins.json neither > the link to /var/lib/vagrant/plugins.json is created, which should be > fine for Vagrant. As soon as some Vagrant plugin is installed, the > %transfiletriggerin kicks in and when the file/link is not present, it > just creates the /usr/share/vagrant/plugins.json. rpm-ostree doesn't execute %transfiletriggerin though. We can look at that, though if vagrant has a %posttrans that regenerated the index, that'd work in both cases. > This way, for normal > Fedora, the plugin.json would be kept in /var/lib/vagrant/plugins.json > with symlink to /usr/share/vagrant/plugins.json while for rpm-ostree, > the /usr/share/vagrant/plugins.json would be regular and the only file. If that's the end result, that seems sane to me. Though I don't quite understand why not just move it to /usr unconditionally, like fontconfig. > Does this work for you? Can you test the latest Copr build [3]? Yeah, I probably can in a bit. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please test Vagrant 1.9.1
Hi Colin, First of all, I am still not fond of moving the plugins.json into /usr. Nevertheless, with the proposed Vagrant 1.9.1 package, things are different then they used to be. Up to now, we were re-configuring Vagrant to search for the plugins.json in /var/lib/vagrant. But this is not easily achievable in more recent Vagrants (actually, nobody noticed that it could already cause some issues even in current Vagrant in Fedora). So from now, I keep Vagrant to look for the plugins.json on the place, where Vagrant expects it, i.e. at /usr/share/vagrant/plugins.json, but this is link to /var/lib/vagrant/plugins.json. Since Vagrant does not need the plugins.json file to be present by default, would this [1] change be sufficient? Basically, if I understand correctly, the %post is not executed by rpm-ostree. In this case, the /usr/share/vagrant/plugins.json neither the link to /var/lib/vagrant/plugins.json is created, which should be fine for Vagrant. As soon as some Vagrant plugin is installed, the %transfiletriggerin kicks in and when the file/link is not present, it just creates the /usr/share/vagrant/plugins.json. This way, for normal Fedora, the plugin.json would be kept in /var/lib/vagrant/plugins.json with symlink to /usr/share/vagrant/plugins.json while for rpm-ostree, the /usr/share/vagrant/plugins.json would be regular and the only file. Does this work for you? Can you test the latest Copr build [3]? Vít [1] http://copr-dist-git.fedorainfracloud.org/cgit/vondruch/vagrant/vagrant.git/commit/?h=f26 [2] http://copr-dist-git.fedorainfracloud.org/cgit/vondruch/vagrant/vagrant.git/tree/vagrant.spec?h=f26#n225 [3] https://copr.fedorainfracloud.org/coprs/vondruch/vagrant/package/vagrant/ Dne 14.2.2017 v 22:29 Colin Walters napsal(a): > > On Tue, Feb 14, 2017, at 08:14 AM, Vít Ondruch wrote: > >> 3) The downside of (1) is that the plugin registration scripts are baked >> into vagrant plugins, I had to apply some hacks to keep the backward >> compatibility with Vagrant plugins currently in Fedora. > While you're working on this, can you change the registration directory > to be in /usr? This is following up on: > https://bugzilla.redhat.com/show_bug.cgi?id=1352152 > which is part of > https://bugzilla.redhat.com/show_bug.cgi?id=1352154 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please test Vagrant 1.9.1
On Tue, Feb 14, 2017, at 08:14 AM, Vít Ondruch wrote: > 3) The downside of (1) is that the plugin registration scripts are baked > into vagrant plugins, I had to apply some hacks to keep the backward > compatibility with Vagrant plugins currently in Fedora. While you're working on this, can you change the registration directory to be in /usr? This is following up on: https://bugzilla.redhat.com/show_bug.cgi?id=1352152 which is part of https://bugzilla.redhat.com/show_bug.cgi?id=1352154 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Please test Vagrant 1.9.1
Hi everybody,
I spent last few days updating Vagrant in Rawhide. As it turned out, it
is quite significant update for several reasons:
1) Upstream changed the way how Vagrant is distributed in upstream RPM.
Hence this is good opportunity to change the way we ship Vagrant to be
close to upstream.
2) The upstream is not using Bundler for managing the Vagrant plugins
anymore, which seems to be change for good.
3) The downside of (1) is that the plugin registration scripts are baked
into vagrant plugins, I had to apply some hacks to keep the backward
compatibility with Vagrant plugins currently in Fedora.
4) And since (3) is PITA, it is good opportunity to use RPM filetriggers
instead. Therefore, I dropped the %vagrant_plugin_register and
%vagrant_plugin_unregister from Vagrant, which in turn means all the
Vagrant plugins in Fedora (maintainers are in CC) will become FTBFS.
I'll go through all the packages and fix them unless you say otherwise
(I might add them into my Copr repository for testing, not sure yet).
Please note that the plugins which are currently in Fedora should keep
working with Vagrant 1.9.1, but the plugins build against Vagrant 1.9.1
will not be compatible with older Vagrant versions, hence I suggest to
add "{,Build}Requires: vagrant >= 1.9.1".
To let everybody chance to test this prior I land the changes in
Rawhide, I built new Vagrant and vagrant-libvirt in Copr:
https://copr.fedorainfracloud.org/coprs/vondruch/vagrant/
You can see the changes in Vagrant here:
http://copr-dist-git.fedorainfracloud.org/cgit/vondruch/vagrant/vagrant.git/commit/?h=f26=34696a703e54a9b37e68e95d034e2a26fbe46d23
And these are the changes in vagrant-libvirt:
http://copr-dist-git.fedorainfracloud.org/cgit/vondruch/vagrant/vagrant-libvirt.git/commit/?h=f26=733217b68fc298e40c45524da4ac9036607d1558
Please give it a try. If no major issues are identified, I'd like to
land this in ~week, prior F27 branching.
Thx
Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
