Hello, Your package (avocado-vt) Fails To Install in Fedora 33: --- can't install python3-avocado-vt-77.0-1.fc33.noarch: - nothing provides python3.8dist(aexpect) needed by python3-avocado-vt-77.0-1.fc33.noarch - nothing provides python3-avocado >= 51.0 needed by python3-avocado-vt-77.0-1.fc33.noarch - nothing provides python3.8dist(avocado-framework) >= 68 needed by python3-avocado-vt-77.0-1.fc33.noarch --- According to a policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks if you won't reply to this bug. Thanks!
Hi, You need to "dnf module enable avocado:latest -y" first to have avocado-vt installed successfully,as avocado stream is banned by default,thanks.
(In reply to lnie from comment #1) > Hi, > You need to "dnf module enable avocado:latest -y" first to have avocado-vt > installed successfully,as avocado stream is banned by default,thanks. In this case, please retire non-modular avocado-vt since that is exactly what fails to install.
> In this case, please retire non-modular avocado-vt since that is exactly > what fails to install. I'm not familiar with modular at all.What should I do if I want to keep avocado-vt, should I build it to a modular?Thanks.
(In reply to lnie from comment #3) > > In this case, please retire non-modular avocado-vt since that is exactly > > what fails to install. > I'm not familiar with modular at all.What should I do if I want to keep > avocado-vt, > should I build it to a modular?Thanks. Well, you said that it is available in a module. It is *also* available as a normal RPM (non-modular). So you need to retire the latter one while keeping former.
> > Well, you said that it is available in a module. It is *also* available as a > normal RPM (non-modular). So you need to retire the latter one while keeping > former. I must have missed something here, would you please tell me where did I said it is available in a module?
(In reply to lnie from comment #5) > > > > Well, you said that it is available in a module. It is *also* available as a > > normal RPM (non-modular). So you need to retire the latter one while keeping > > former. > > I must have missed something here, would you please tell me where did I said > it is available in a module? In the comment #1. > You need to "dnf module enable avocado:latest -y" first to have avocado-vt > installed successfully,as avocado stream is banned by default,thanks.
Hi, Sorry for not having said it clearly.My package is a normal package avocado-vt,and it depends on *avocado* which is a modular, the default stream of *avocado*(actually all modular) is banned according to https://pagure.io/fesco/issue/2341#comment-628267.
(In reply to lnie from comment #7) > Hi, > Sorry for not having said it clearly.My package is a normal package > avocado-vt,and it depends on *avocado* which is a modular, > the default stream of *avocado*(actually all modular) is banned according to > https://pagure.io/fesco/issue/2341#comment-628267. non-modular RPMs can not depend on modular RPMs, so you need to make avocado-vt a modular rpm inside avocado module and retire non-modular RPM.
> > non-modular RPMs can not depend on modular RPMs, so you need to make > avocado-vt a modular rpm inside avocado module and retire non-modular RPM. Thanks for your information,I'm gonna to contact the maintainer of avocado.
Or, avocado can be made non-modular instead.
Hello, This is the first reminder (step 3 from https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs).
Hi, I'm still waiting for the response from the avocado maintainer.
Hi, The maintainer of avocado suggests me to make "avocado-vt" a module which depends on module avocado.I have a concern: we have to "dnf module enable avocado:latest" first to install *avocado*,so if I add avocado as a requires of avocado-vt, will dnf do "dnf module enable avocado"(or something similar) automatically? If not,then modular avocado-vt will not be successfully installed either.I have no idea about how the modular dependence works,so dose he. Actually,I have asked him to provide both modular and non-modular avocado rpms at first,but he said the general rule is "modular rpms should not be duplicated as non-modular rpms"? His second choice is including avocado-vt inside the "avocado" module.
Let me first start with a quick summary of status quo: avocado is only available as a module. The module consists of two src rpms: python-aexpect and python-avocado. The module has two streams: latest and 69lts. In latest, both rpms are built in the latest version. In 69lts, the rpms are built from "stable". python3-avocado-vt requires python3.8dist(aexpect) and python3.8dist(avocado-framework). There are a few options here: 1. turning python-avocado-vt into a module: + avocado module can stay untouched - additional work - poor discoverability for users (dnf search avocado will yield no hits) - poor usability for users, because the module needs to be enabled before use - the problem is pushed repeated for any package that would like to depend on python-avocado-vt: it too would need to be modularized. - contributions of other maintainers to python-avocado-vt become less likely because of the additional overhead and lack of clarity. (I'm thinking about some Python-SIG member contributing some drive-by cleanups or a FTBFS fix on python version bumps.) 1b. moving the python-avocado-vt rpm into the avocado module + very small amount of work - the usability problems as with 1 - the problem for potential dependent packages as with 1 - independent rpms are artificially tied together into one module 2. retiring python-avocado-vt. Obviously not a good solution. 3. turn avocado:latest module into a non-modular rpm, keep avocado:69lts a module - a bit of work for avocado maintainer (but the rpms definitions are already there, so it's mostly a question of doing fedpkg build and so minor adjustments, no new entities are needed). + avocado is discoverable by 'dnf list' and 'dnf search' + python-avocado-vt is happy and any subsequent packages depending on either of the packages provided by avocado are happy too. ~ anyone wanting to depend on the non-latest version of avocado has to use the module (no change here) 4. turn avocado:latest into non-modular rpms, turn avocado:69lts into compat packages like python-aexpectNN and python-avocado69 (naming To-Be-Figured-Out). - work for avocado maitainer - two new repos for the compat packages would need to be created (but not review is needed, since compat packages are exempt from review) + same advantages as above + the compat version is discoverable by dnf search + other rpms in fedora can easily depend on the compat package ~ the compat packages would still not be co-installable with the normal ones (no change) My evaluation: 3 is the only solution that fixes the issue without creating much work and without causing further problems. 4 is OK, but requires additional work, and since the packages would not be co-installable, there isn't much gain for the user. 2 is bad. 1 and 1b are more work than 3 and cause further problems down the road. @sgallagh: if I missed anything in the evaluation, please fill it in.
There is also: 5. Request permission from FESCo to make avocado:latest a default module stream (since as a "rolling" stream it will not have to deal with the as-yet unresolved upgrade issues). This would make python-avocado available to anyone who wants it for a non-modular dependency while not adding additional load onto the Avocado maintainer. If we were to go with option 3, I'd recommend that we actually keep the latest stable release in Fedora proper and keep the avocado:latest stream as an alternative, since it may be unstable, make incompatible changes, etc.
(In reply to Stephen Gallagher from comment #15) > There is also: > > 5. Request permission from FESCo to make avocado:latest a default module > stream (since as a "rolling" stream it will not have to deal with the as-yet > unresolved upgrade issues). This would make python-avocado available to > anyone who wants it for a non-modular dependency while not adding additional > load onto the Avocado maintainer. The vote against default streams was done because there were significant drawbacks in functionality. This situation hasn't changed. There are some development proposals, but that's all. Thus such a default stream would be unlikely to pass, and I don't think this is a realistic proposal. > If we were to go with option 3, I'd recommend that we actually keep the > latest stable release in Fedora proper and keep the avocado:latest stream as > an alternative, since it may be unstable, make incompatible changes, etc. Yeah. That might be better. I assumed "latest" is OK, but it's up to the maintainer to pick which version is the most suitable for Fedora. That also goes against making it a default module, since we're back to upgrade issues.
(In reply to Igor Raits from comment #2) > In this case, please retire non-modular avocado-vt since that is exactly > what fails to install. Uh no. The correct solution is to unretire the non-modular avocado instead. Making that package module-only is what caused this breakage. This mess is exactly why I have always pointed out that it is not sufficient (and actually counterproductive) to only ban default streams, we also need to ban module-only packages. IMHO, all packages MUST have a default version and that default version MUST be provided as a non-modular RPM.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #14) > 4. turn avocado:latest into non-modular rpms, turn avocado:69lts into compat > packages > like python-aexpectNN and python-avocado69 (naming To-Be-Figured-Out). > - work for avocado maitainer > - two new repos for the compat packages would need to be created (but not > review is needed, > since compat packages are exempt from review) > + same advantages as above + the compat version is discoverable by dnf search > + other rpms in fedora can easily depend on the compat package > ~ the compat packages would still not be co-installable with the normal ones > (no change) 4.1. Same, but actually make the packages co-installable, e.g., by renaming the provided Python module to something like avocado_lts or avocado69, and patching packages that do not work with the current avocado to use "import avocado_lts as avocado" or "import avocado69 as avocado" instead of "import avocado". (The patch can even be done by a global sed.) IMHO, that would be the optimal solution, because it means that leaf packages using the different versions of avocado will not conflict with each other.
> 4.1. Same, but actually make the packages co-installable, e.g., by renaming the provided Python module to something like avocado_lts or avocado69 This is an option, but the renaming is rather problematic, and requires modification of both avocado and all packages using it. I wouldn't try to do this unless there's a very strong requirement to allow coinstallability.
Thanks for your reply.I have rebuilt avocado-vt to a module, and you can install it successfully on rawhide now by "dnf module install avocado-vt/common",so I'm gonna to close this bug.
(In reply to lnie from comment #20) > Thanks for your reply.I have rebuilt avocado-vt to a module, > and you can install it successfully on rawhide now by "dnf module install > avocado-vt/common",so I'm gonna to close this bug. Note that modular repositories might not be enabled (installed) anymore in future (https://src.fedoraproject.org/rpms/fedora-repos/pull-request/62) so that people who want to use avocado can have some troubles. Anyway, since the non-modular package is still broken, you need to retire it in Rawhide.
Hi, The non-modular package has already been retired,thanks.
*** Bug 1833889 has been marked as a duplicate of this bug. ***