https://bugzilla.redhat.com/show_bug.cgi?id=1997994
--- Comment #13 from hardt(a)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/...
> 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