https://bugzilla.redhat.com/show_bug.cgi?id=1997994 --- Comment #13 from hardt@xxxxxxx --- (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/oidc-agent.spec > > 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 -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1997994 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
