Re: Fedora EPEL - sequoia-sq package and "cli breakages"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 13, 2025 at 11:53 AM Clemens Lang <cllang@xxxxxxxxxx> wrote:
>
> Hi David,
>
> > On 13. Jan 2025, at 11:38, David Sommerseth via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> >
> > Has something changed in the Fedora EPEL packaging policy in regards to package stability?
>
> Just for the record: I’m explicitly not answering this question. I’m also not the maintainer for sequoia-sq.

I am, so let me answer the question.

> > Since the updates which has arrived since early December 2024, the updates to sequoia-sq has twice broken my automated scripts.
>
> sequoia-sq did not yet have an upstream 1.0 release and did simply not yet have a stable command line interface. With the release of 1.0, upstream will now support a stable command line interface.

This isn't new since December 2024, the sq CLI was *never* stable, and
basically every 0.x -> 0.(x+1) release broke some part of the
command-line API. The upstream project made it quite explicit that the
CLI would only be stable going forward after the 1.0.0 release.

> > The first update which broke my scripts changed --recipient-file to --for-file.  And on Friday another update arrived which added now a required --without-signature or a --signer-* argument.
> >
> > Rest assure, I understand the importance of upgrading packages, add improvements and even the signing aspect in PGP.  But my understanding has been that the EPEL packages should be more stable than this.
>
> I don’t think EPEL can reasonably add stability guarantees that upstream does not provide except by pinning a package at an old version, but that would mean that EPEL would essentially package unsupported software.

Yes, this. I can't as a package maintainer provide more stability
guarantees than what upstream considers stable. And providing
stability for something that's explicitly unstable and subject to
change would just mean that I can't push updates *at all*, which isn't
what you want for a crypto-related program, I think.

With hindsight, it might have been "better" to not provide sq packages
for EPEL 9 *at all* until the 1.0.0 release was out. But there was
user demand for it, so I built it for EPEL 9, under the assumption
that users would know that the sq CLI is not stable yet.

Fabio
-- 
_______________________________________________
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux