https://bugzilla.redhat.com/show_bug.cgi?id=1997994
--- Comment #13 from hardt@kit.edu --- (In reply to Ben Beasley from comment #12)
Thanks! I’ve skimmed your responses.
We've addressed this for debian, too. Essentially the packaged version is too old for our requirements (5.1.3), which is not available on most distributions.
Unfortunately, I’m not aware of any way around the ban on pre-compiled CSS. The current guidelines around JavaScript and web assets are very strict—arguably, so strict that modern web assets usually can’t be packaged.
Ok, with dropping the -desktop subpackage, we're no longer include bootswatch/bootstrap
It's still being built (since I don't want to touch the Makefile right now), but none of this ends up in any output package. I suppose the right process is to remove the files and patch the Makefile in the %prep step of the fedora specfile, right?
for list I didn't find a package
It can be packaged as a dependency.
Who is supposed to do this? Is there a process, or will I (i.e. upstream) be left with this?
For mustache, developer checked, and claims the existing packages are not what he needs.
As in, https://src.fedoraproject.org/rpms/mustache can’t be used because it is not actually the same library, or the upstream version of https://gitlab.com/jobol/mustach (not currently packaged in Fedora as far as I can tell) can’t be used, e.g. because the version in oidc-agent is forked?
Bundling is allowed in Fedora, but there are specific conditions that have to be met, and the bundling has to be properly justified and indicated with virtual Provides. For example “nobody has packaged the dependency yet” does not allow you to bundle it, but “upstream doesn’t support building against an external library and I publicly contacted them at https://example.com/link about whether it could be possible in the future” does.
Since we don't build the -desktop subpackage any longer, we don't need to address this right now. For the record: we use the mustache version plain from github, so once there is another package providing it, we can revisit the -desktop subpackage.
Right. What would you suggest? All conditionals in the main specfile and then includes to distribution specific ones?
Especially considering Fabio’s reminder about non-Fedora and non-EPEL conditionals, I think you’ll just need to commit to the idea that you will need to merge changes into the Fedora spec file, and will not be able to maintain a single source for all distributions.
I guess this Fedora spec file is kept in a different repository, to which the package maintainer has access? I'm not really sure how my interface to this is.
I was building here [1] using our upstream specfile [2]
Copr is als the reason why I don't understand how to use different specfiles for different distributions.
[1] https://copr.fedorainfracloud.org/coprs/marcvs/oidc-agent/build/4686340/ [2] https://github.com/indigo-dc/oidc-agent/blob/address-rh-bugzilla-1997994/rpm...
We did this, so updates to manually installed oidc-agent packages would still work (even though we've split it into oidc-agent-cli and oidc-agent-desktop). But since you say _strongly_ I take it that meta-packages are not intended to exist here, and I removed the %files section. (Please tell me if there is another way to have such a meta package).
In this case, I missed that oidc-agent had “Requires: %{name}-desktop%{?_isa} = %{version}-%{release}”, so I thought it was just a useless nearly-empty package rather than a metapackage. Metapackages are common in Fedora. Usually they have an empty %files section, and that seems to make sense here since other subpackages already have the license and readme. Please feel free to use oidc-agent as a metapackage for convenient installation.
If you are ever inclined to use a metapackage strictly for upgrade compatibility, Providing the old name is usually a better choice. See https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or- replacing-existing-packages for an example, but note that you don’t need the full Package Renaming Process to rename a subpackage.
Ok; I've added it back in (but it does no longer depend on the -desktop subpackage (obviously)
Using [1] and [2], I'm left with three rpmlint warnings that I didn't manage to fix:
- oidc-agent.spec: W: invalid-url Source0: oidc-agent-4.3.2.tar.gz => I didn't ever specify that URL - liboidc-agent-devel.x86_64: W: dangling-relative-symlink /usr/lib/.build-id/44/d338004058c396a41f2c9b4615f269a1a6c0a4 ../../../../usr/bin/oidc-prompt => .build-id is not mentioned in any %files directive. %excluding it didn't help either. I hope this is just an artifact of my local build docker. - oidc-agent-cli.x86_64: W: invalid-license LGPL-2.1+ => This license is specified by the author/owner of src/oidc-gen/qr.c