Petr and Daniel, thanks a lot for your replies.
I hope some of mentioned limitations could be reflected in the
modularity documentation. I read through most of it (including the
drafts for f33 change) and I don't feel that the consequences of adding
package to the module are clearly communicated.
And maybe something could be added to the modulemd spec to reflect that
the specific package is no longer required starting from release x. I
don't expect that to work from updates-modular for branched releases,
but having the ability to drop packages from module on a development
release would be awesome.
On 7/20/20 4:46 AM, Petr Pisar wrote:
> On Fri, Jul 17, 2020 at 02:14:49PM -0700, Aleksei Bavshin wrote:
>> The real question is how to do the change in f33 considering that f32
>> and f33 modules must be built from the same modulemd file.
>
> You wrap a %files section of the package you want to remove with a condition
> based on the Fedora version:
>
> %if %{fedora} < 33
> %files
> ...
> %end
>
> This will cause the when building the module component, rpmbuild won't produce
> the unwanted binary package on F33, but it will produce it on F32.
>
> The only problem is if that is the only binary package produced by the spec
> file. Then rpmbuild would report an error, because it would consider it
> a packaging mistake. But it can be worked around by produced a dummy package
> instead:
>
> %if %{fedora} < 33
> %files
> ...
> %else
> %files -n dummy
> %end
>
> and filtering out the dummy package from the module on modulemd level with
> /data/filetr/rpms/dummy entry.>
>> And now I'm curious what would happen if I specify `platform: [-f33]`
>> and publish new module build. Would that remove previously published
>> metadata from rawhide?
>
> No. Rawhide repository is composed from the latest builds tagged into
> a rawhide tag. That means Rawhide would still contain the last module built
> from f33 platform.
>
>> I guess the right answer is somewhere around servicelevels and `eol`
>> specification.
>>
> Theoretically yes. You can file a releng request
> <https://pagure.io/releng/new_issue> of moduel_eol type to shorten the EOL.
> But I worry that a compose process does not respect the EOL dates and instead
> the EOLed modules are removed from a compose configuration by relengs
> manually once before branching a new Fedora release (33 is the next one).
>
> -- Petr
--
With best regards,
Aleksei Bavshin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
