1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Re: fluster add epoch

    From Soren Stoutner@21:1/5 to Christopher Obbard on Sat Mar 22 13:35:49 2025
    Copy: obbardc@debian.org (Christopher Obbard)

    On Saturday, March 22, 2025 1:09:29 PM Mountain Standard Time
    Christopher Obbard wrote:
    Hi!

    For the package fluster, upstream at
    http://github.com/fluendo/fluster/, we have a slight mistake with
    the upstream versioning and I would like to add an epoch

    The current version in debian is 1.0.1+git20231211.d9106f5-1 (since
    upstream had released 1.0.1 but later deleted the tag) and now
    upstream latest version is 0.2.0+git20250319.30ac3a8

    I am proposing to add an epoch; e.g 1:0.2.0+git20250319.30ac3a8 to
    make the mistakes from the past go away.

    Does it sound OK to others ?

    Does upstream plan to release a 1.0.1 sometime in the future?

    If so, I would probably go with a 1.0.1+really0.2.0 release until
    upstream catches up.

    Typically, I don’t like to go with an epoch unless upstream does
    something that will never be compatible, like switching from a date
    release of 2025-01-27 to 1.0.1.

    --
    Soren Stoutner
    soren@debian.org
    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmffHyUACgkQwufLJ66w tgN39g//bvAKDdy68JgK8sDxYLOdV78LCxZWam8RLsUP1h4vyivWVWgCDyckrcBM fD9I3QRcVwQZ9BRHp8A3r+oikHPqWsRtCtE56eFyldrAMDvXyNYbcGll30AMUt+X G5ISi584A8JBeGIE3WECQ0mUHjKIOsg3HsNbI7SMeLgkPXEJqphWbs1eNwIxGCVh 4k1YcPINGk/+QosDguYCccmqwT35FObCbNikpls42RU2HsKkZuTecT2p0B1aVGz3 rt2xt78FKFFo1UAiEXYfpOdTv9US+gjQTsbr/nRFKzHZAxqsNhDKJge0Eq1aeopl 8Gwvg+1+GL8qtbTPBSwWovSUHg6PK4uWUNtHc/8vBleNzex1b+6K7S+PRNeWctvL pZAJiz+ext/TflzBjvUxHuLzfxawzDgjPivniTRNwAwN8j9EgWC5X/IfWbxe0E59 5xFlLlDmdh4sL6HDu/qQw21tvWTN5p/8+sHD6JPlwB5qZp/pIy+F4Qu9shWizMGX yx4Dd+stuHvGD8dpo5RrKDgCAIcONJsQEnY166pX187DeaVM0+VeS8tDeOb5nhUi GGs6vZsit4ZWtj4K6iEbWu/ttmaVjPVJxNhe7MC0L4meQTAA7jMXzKiRW1Iayr2o fOKkZf4iUXCNFq6YniWYYuS7YLNMonRyBJUst32RlPqIBLIAeMo=
    =nN88
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Christopher Obbard@21:1/5 to All on Sat Mar 22 21:30:01 2025
    Hi!

    For the package fluster, upstream at
    http://github.com/fluendo/fluster/, we have a slight mistake with the
    upstream versioning and I would like to add an epoch

    The current version in debian is 1.0.1+git20231211.d9106f5-1 (since
    upstream had released 1.0.1 but later deleted the tag) and now
    upstream latest version is 0.2.0+git20250319.30ac3a8

    I am proposing to add an epoch; e.g 1:0.2.0+git20250319.30ac3a8 to
    make the mistakes from the past go away.

    Does it sound OK to others ?

    Cheers!

    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Christopher Obbard@21:1/5 to Soren Stoutner on Sun Mar 23 22:10:01 2025
    Hi Soren,

    On Sat, 22 Mar 2025 at 20:35, Soren Stoutner <soren@debian.org> wrote:
    On Saturday, March 22, 2025 1:09:29 PM Mountain Standard Time
    Christopher Obbard wrote:
    Hi!

    For the package fluster, upstream at
    http://github.com/fluendo/fluster/, we have a slight mistake with
    the upstream versioning and I would like to add an epoch

    The current version in debian is 1.0.1+git20231211.d9106f5-1 (since upstream had released 1.0.1 but later deleted the tag) and now
    upstream latest version is 0.2.0+git20250319.30ac3a8

    I am proposing to add an epoch; e.g 1:0.2.0+git20250319.30ac3a8 to
    make the mistakes from the past go away.

    Does it sound OK to others ?

    Does upstream plan to release a 1.0.1 sometime in the future?

    I guess eventually upstream will release 1.0.1 but I don't think it
    will be for a long while.
    They had a few issues with their github release pipeline last year,
    but all seems to be OK now.


    If so, I would probably go with a 1.0.1+really0.2.0 release until
    upstream catches up.

    Typically, I don’t like to go with an epoch unless upstream does
    something that will never be compatible, like switching from a date
    release of 2025-01-27 to 1.0.1.

    I am happy to do that rather than add an epoch; does anyone else have
    any opinions ?

    I thought an epoch would be cleaner here personally, but I don't have
    any actual upstream Debian
    packaging experience with epochs. When developing custom distros with
    custom (not suitable for Debian)
    packages we added them fairly frequently when bootstrapping things and
    upstream changing things.
    But it seems like adding epochs in Debian is a much more conservative
    decision? It'd be interesting to
    hear more about this, I possibly need some history lesson for
    real-world case where adding epoch
    is dangerous ;-).


    Cheers!

    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carsten Schoenert@21:1/5 to All on Mon Mar 24 09:00:02 2025
    Hello Christopher,

    Am 23.03.25 um 22:52 schrieb Christopher Obbard:

    I guess eventually upstream will release 1.0.1 but I don't think it
    will be for a long while.
    They had a few issues with their github release pipeline last year,
    but all seems to be OK now.

    if you don't have statement from upstream about there future release
    plannings it's just pure guessing what can happen.
    Looking at the releases over time I don't have the impression it will
    soon come to a release 1.x.

    ...
    I am happy to do that rather than add an epoch; does anyone else have
    any opinions ?
    I thought an epoch would be cleaner here personally, but I don't
    have any actual upstream Debian packaging experience with epochs.
    When developing custom distros with custom (not suitable for Debian)
    packages we added them fairly frequently when bootstrapping things
    and upstream changing things. But it seems like adding epochs in
    Debian is a much more conservative decision? It'd be interesting to
    hear more about this, I possibly need some history lesson for real-
    world case where adding epoch is dangerous ;-).

    Yeah, epochs are for ever, and they confuse the "normal" users often as
    they don't understand why they are in the version string.

    So maybe another option is to introduce a new src and binary package
    that can replace the existing package over time.

    Looking at PyPi and into the pyproject.toml file the package seems to
    have the real name 'fluster-conformance'.

    https://pypi.org/project/fluster-conformance/ https://github.com/fluendo/fluster/blob/master/pyproject.toml#L6

    So you could create a new src package with the name
    'fluster-conformance' that is providing 'python3-fluster' and uses Breaks/Replace and optional Provides for fluster.
    Once you want to keep the binary name this all will not work because the version issue plus package name is still the same then!

    There is a wiki page existing about how to do some transitions of packages. https://wiki.debian.org/PackageTransition

    I haven't looked at all details so maybe my suggestion is also not
    sufficient in the end and using an epoch is still the best solution.

    --
    Regards
    Carsten

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)