Hi, I'm quvi's packager. I have a problem with F16. Here is the situation :
- F15 provides quvi (the libquvi, the scripts, and the executable file) 0.2.16.X : the "legacy" version, still maintained
- F16 provides quvi (the libquvi, the scripts, and the executable file) 0.2.19 : not maintained anymore. It has been replaced by libquvi 0.4.x when F16 has been released
- rawhide provides libquvi 0.4.0, libquvi-scripts 0.4.2 and quvi 0.4.1, 3 different packages. : the new version, that has replaced 0.2.19 branche.
So now, F15 and rawhide both have a maintained version, but F16 provides a quvi that is not maintained. Problems will appear because the websites handeled by libquvi often change.
I thought at first to downgrade the F16 version, from 0.2.19 to 0.2.16 version, instead of backporting 0.4.x to F16 to not force a package rebuild for dependancies, because of the package split. But 0.2.16, 0.2.19 and 0.4.x have different .so version, so a rebuild will be forced in both cases.
There are 3 or 4 packages that need to be rebuilded. It has been done in rawhide, with no problem (only one package needed a patch, provided by upstream, to compile with libquvi 0.4).
My question is : what must I do ? backport 0.4.x ? downgrade to 0.2.16 ? keep 0.2.19 ?
I can rebuild all the dependancies. I just need help to be sure of what to do, check, etc .... I'm not really confortable with this situation.
Regards,
Fabien Nicoleau
On 12/03/2011 05:32 PM, Nicoleau Fabien wrote:
So now, F15 and rawhide both have a maintained version, but F16 provides a quvi that is not maintained. Problems will appear because the websites handeled by libquvi often change.
[...]
My question is : what must I do ? backport 0.4.x ? downgrade to 0.2.16 ? keep 0.2.19 ?
At least postpone dealing with it until the anticipated problems (you mentioned "problems will appear") become reality? If nothing's broken at the moment, don't try to fix anything yet...
Ville Skyttä wrote:
At least postpone dealing with it until the anticipated problems (you mentioned "problems will appear") become reality? If nothing's broken at the moment, don't try to fix anything yet...
I think there already are some fixes of that kind, and I also don't see what waiting would accomplish. It would have to be bumped sooner or later anyway.
The set of packages to rebuild is small, let's just issue one small grouped update and be done with it.
Kevin Kofler
On 03/12/2011 23:26, Kevin Kofler wrote:
Ville Skyttä wrote:
At least postpone dealing with it until the anticipated problems (you mentioned "problems will appear") become reality? If nothing's broken at the moment, don't try to fix anything yet...
I think there already are some fixes of that kind, and I also don't see what waiting would accomplish. It would have to be bumped sooner or later anyway.
The set of packages to rebuild is small, let's just issue one small grouped update and be done with it.
Kevin Kofler
I actually prefer fix the things now. Just to be sure, what I have to do is : - open a bz ticket to create git access for libquvi-scripts and libquvi in F16 (quvi already exists) - commit and push all the changes for libquvi-scripts, libquvi, quvi and the packages depending on quvi - ask rel-eng to make a chain-build for all the pacakges - create an update in bodhi with all the new packages ?
Fabien Nicoleau
Nicoleau Fabien wrote:
- open a bz ticket to create git access for libquvi-scripts and libquvi
in F16 (quvi already exists)
Actually, the new branch request should be filed in the existing review ticket, see: https://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Req...
- commit and push all the changes for libquvi-scripts, libquvi, quvi and
the packages depending on quvi
Right.
- ask rel-eng to make a chain-build for all the pacakges
No. A chain-build for a released Fedora is only possible in a dedicated tag, and in this case I don't think it's worth the overhead of a dedicated tag, so rel-eng would probably reject that request. Instead: * build libquvi * request a buildroot override through: https://admin.fedoraproject.org/updates/override/list * wait ~30-60 minutes for the override to take effect (Koji needs time to compose a new buildroot repository with the new override). You can use: koji wait-repo --build=libquvi-$version-$release f16-build to check, it will return when the new package is available in the buildroot (or immediately if it already was in the buildroot when you ran the command). * if any other quvi package is needed to build dependent packages, do the same for those * build the dependent packages * delete the buildroot override through: https://admin.fedoraproject.org/updates/override/list when you don't need it anymore
- create an update in bodhi with all the new packages
Yes.
Kevin Kofler
Le 04/12/2011 07:14, Kevin Kofler a écrit :
Nicoleau Fabien wrote:
- open a bz ticket to create git access for libquvi-scripts and libquvi
in F16 (quvi already exists)
Actually, the new branch request should be filed in the existing review ticket, see: https://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Req...
- commit and push all the changes for libquvi-scripts, libquvi, quvi and
the packages depending on quvi
Right.
- ask rel-eng to make a chain-build for all the pacakges
No. A chain-build for a released Fedora is only possible in a dedicated tag, and in this case I don't think it's worth the overhead of a dedicated tag, so rel-eng would probably reject that request. Instead:
- build libquvi
- request a buildroot override through:
https://admin.fedoraproject.org/updates/override/list
- wait ~30-60 minutes for the override to take effect (Koji needs time to
compose a new buildroot repository with the new override). You can use: koji wait-repo --build=libquvi-$version-$release f16-build to check, it will return when the new package is available in the buildroot (or immediately if it already was in the buildroot when you ran the command).
- if any other quvi package is needed to build dependent packages, do the
same for those
- build the dependent packages
- delete the buildroot override through:
https://admin.fedoraproject.org/updates/override/list when you don't need it anymore
- create an update in bodhi with all the new packages
Yes.
Kevin Kofler
Thank you very much. The update is now in testing.
Fabien Nicoleau
-
Fabien Nicoleau -
Kevin Kofler -
Ville Skyttä