Re: Sub-package dropped upstream
On Thu, 9 Jan 2014 12:08:49 -0800, Jorge Gallegos wrote: Hi, I maintain the uwsgi package for fedora, which optionally builds a bunch of modules to integrate with several other languages. One of the plugins got recently removed upstream but it hasn't got any replacements yet (see the top of http://uwsgi-docs.readthedocs.org/en/latest/Erlang.html) Currently f19 and f20 have 1.9.19 available, and I would like to update to 1.9.21 but that would mean I have to deprecate the existing package uwsgi-plugin-erlang. Is this the correct approach? adding an obsoletes tag in the spec for uwsgi-plugin-erlang 1.9.20 ? That would be the only way to withdraw the package from users' installations, especially if not obsoleting it would result in broken dependencies. https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages Depending on how popular the package might be, such breakage could annoy users. Tangential question, do we have statistics of how many times this (or any other) package has been downloaded? Hardly feasible, given that every mirror server would need to count downloads and submit the results to the Fedora Project, and then one could still not conclude safely whether a package has been installed actually and is still in use (or has been downloaded/mirrored only). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sub-package dropped upstream
Yes, still it's an interesting issue... perhaps one count how many which actually are installed, but many problems also here: users privacy/opt-in, easily spoofed, infrastructure. In any case it would be great to have some estimate on this. On Thu, Jan 9, 2014 at 9:40 PM, Michael Schwendt mschwe...@gmail.comwrote: On Thu, 9 Jan 2014 12:08:49 -0800, Jorge Gallegos wrote: Hi, I maintain the uwsgi package for fedora, which optionally builds a bunch of modules to integrate with several other languages. One of the plugins got recently removed upstream but it hasn't got any replacements yet (see the top of http://uwsgi-docs.readthedocs.org/en/latest/Erlang.html) Currently f19 and f20 have 1.9.19 available, and I would like to update to 1.9.21 but that would mean I have to deprecate the existing package uwsgi-plugin-erlang. Is this the correct approach? adding an obsoletes tag in the spec for uwsgi-plugin-erlang 1.9.20 ? That would be the only way to withdraw the package from users' installations, especially if not obsoleting it would result in broken dependencies. https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages Depending on how popular the package might be, such breakage could annoy users. Tangential question, do we have statistics of how many times this (or any other) package has been downloaded? Hardly feasible, given that every mirror server would need to count downloads and submit the results to the Fedora Project, and then one could still not conclude safely whether a package has been installed actually and is still in use (or has been downloaded/mirrored only). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sub-package dropped upstream
On Thu, 9 Jan 2014 22:20:10 +0100, Alec Leamas wrote: Yes, still it's an interesting issue... perhaps one count how many which actually are installed, Installed and used actively would be more interesting. Especially with regard to optional plugins, which perhaps are not loaded/executed at runtime automatically. For example, multimedia users follow instructions found on the web that lead to installing all codec packages, whether they need them or not. Watching statistics you might think hey, there are WavPack or Musepack users, but maybe they never use files of that type. but many problems also here: users privacy/opt-in, easily spoofed, infrastructure. And it wouldn't force a packager in any way, maybe serve as some minor influence only. It would not be the first plugin/subpackage that has been discontinued during the lifetime of a distribution. If a package were considered popular enough, the packager would not want to upgrade the software to a newer version that removes the package? There are other more important factors when considering a version upgrade. And probably most important, you cannot get an obsolete package to reinstall automatically once it would become available again. User would need to take notice and reinstall manually (unless packager plays tricks or makes it a new requirement). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sub-package dropped upstream
On Thu, Jan 09, 2014 at 10:45:44PM +0100, Michael Schwendt wrote: On Thu, 9 Jan 2014 22:20:10 +0100, Alec Leamas wrote: Yes, still it's an interesting issue... perhaps one count how many which actually are installed, Installed and used actively would be more interesting. Especially with regard to optional plugins, which perhaps are not loaded/executed at runtime automatically. For example, multimedia users follow instructions found on the web that lead to installing all codec packages, whether they need them or not. Watching statistics you might think hey, there are WavPack or Musepack users, but maybe they never use files of that type. it'd be interesting to know how debian QA takes metrics like these: http://qa.debian.org/popcon-graph.php?packages=python-bottle%2C+python-flaskshow_installed=onwant_legend=onfrom_date=to_date=hlght_date=date_fmt=%25Ybeenhere=1 I haven't looked but pretty sure these are not recorded via some unauthorized callback (being debian and all), perhaps these are just rough download statistics. but many problems also here: users privacy/opt-in, easily spoofed, infrastructure. And it wouldn't force a packager in any way, maybe serve as some minor influence only. It would not be the first plugin/subpackage that has been discontinued during the lifetime of a distribution. If a package were considered popular enough, the packager would not want to upgrade the software to a newer version that removes the package? There are other more important factors when considering a version upgrade. And probably most important, you cannot get an obsolete package to reinstall automatically once it would become available again. User would need to take notice and reinstall manually (unless packager plays tricks or makes it a new requirement). The package may not come back any time soon, and I actually have no idea if patching it back from the old sources would be feasible (I haven't looked to what extent it is broken.) If it does come back in the future I understand it should be named something else... should that potential future package _also_ obsolete this one? (I don't think so?) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- ~kad pgpI50ulv0_vh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sub-package dropped upstream
On Thu, Jan 09, 2014 at 02:38:50PM -0800, Jorge Gallegos wrote: On Thu, Jan 09, 2014 at 10:45:44PM +0100, Michael Schwendt wrote: On Thu, 9 Jan 2014 22:20:10 +0100, Alec Leamas wrote: Yes, still it's an interesting issue... perhaps one count how many which actually are installed, Installed and used actively would be more interesting. Especially with regard to optional plugins, which perhaps are not loaded/executed at runtime automatically. For example, multimedia users follow instructions found on the web that lead to installing all codec packages, whether they need them or not. Watching statistics you might think hey, there are WavPack or Musepack users, but maybe they never use files of that type. it'd be interesting to know how debian QA takes metrics like these: http://qa.debian.org/popcon-graph.php?packages=python-bottle%2C+python-flaskshow_installed=onwant_legend=onfrom_date=to_date=hlght_date=date_fmt=%25Ybeenhere=1 I haven't looked but pretty sure these are not recorded via some unauthorized callback (being debian and all), perhaps these are just rough download statistics. Hah!, found it right after I sent the email: http://popcon.debian.org but many problems also here: users privacy/opt-in, easily spoofed, infrastructure. And it wouldn't force a packager in any way, maybe serve as some minor influence only. It would not be the first plugin/subpackage that has been discontinued during the lifetime of a distribution. If a package were considered popular enough, the packager would not want to upgrade the software to a newer version that removes the package? There are other more important factors when considering a version upgrade. And probably most important, you cannot get an obsolete package to reinstall automatically once it would become available again. User would need to take notice and reinstall manually (unless packager plays tricks or makes it a new requirement). The package may not come back any time soon, and I actually have no idea if patching it back from the old sources would be feasible (I haven't looked to what extent it is broken.) If it does come back in the future I understand it should be named something else... should that potential future package _also_ obsolete this one? (I don't think so?) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- ~kad -- ~kad pgpgbpHaw4nIi.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sub-package dropped upstream
On Thu, 9 Jan 2014 14:38:50 -0800, Jorge Gallegos wrote: The package may not come back any time soon, and I actually have no idea if patching it back from the old sources would be feasible (I haven't looked to what extent it is broken.) If it does come back in the future I understand it should be named something else... should that potential future package _also_ obsolete this one? (I don't think so?) If upstream renames it, too, moving the Obsoletes to that _new_ subpackage doesn't add much value, since it would only affect people who have kept the old package. If upstream doesn't rename it, you can let the package return with a %version-%release higher than what you've specified in the Obsoletes tag. The packaging guidelines section explains that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
