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

  • debian/upstream/metadata (Re: git branches vs debian specific git tools

    From Charles Plessy@21:1/5 to All on Wed May 14 14:30:01 2025
    Le Wed, May 14, 2025 at 10:59:48AM +0200, PICCA Frederic-Emmanuel a �crit :

    d/upstream/metadata (what for ?)

    Hi!

    When I created debian/upstream.metadata I intended that would contain metadata that is not required for package building and that can change or grow independently of the source code, for instance URLs to donation/sponsor pages, bibliographic references, upstream VCS URL, etc.

    At the core of my original design, there was the idea that this file is reachable through the Debian source VCS, which is documented in debian/control, an that changes in these files can be monitored directly from there, ahead of package updates. Because rebuilding a package just for adding information on how to pay a coffee to the developer is not very logical, if one things about it from a different point of view.

    I wrote a collector which failed to be stable, and Andreas replaced it with a more pragmatic solution that feeds some of the data to the UDD so that websites can display fresh information. Also, the file was moved to debian/upstream because somebody envisionned that this directory would be populated by more files in the future.

    https://wiki.debian.org/UpstreamMetadata

    That's pretty much where we are now. This was done in the pre-Salsa time, and if people get excited about the concept, I guess that Salsa offers new opportunities to play with the concept!

    Have a nice day,

    --
    Charles Plessy Nagahama, Yomitan, Okinawa, Japan
    Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy
    - You do not have my permission to use this email to train an AI -

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?@21:1/5 to All on Wed May 14 21:00:03 2025
    +Jelmer, who is the maintainer of the metadata specification

    https://wiki.debian.org/UpstreamMetadata

    That's pretty much where we are now. This was done in the pre-Salsa time, and
    if people get excited about the concept, I guess that Salsa offers new opportunities to play with the concept!

    This wiki page is partially outdated. I'd recommend reading https://dep-team.pages.debian.net/deps/dep12/ instead. However it is
    also pending to be polished and finalized by via https://salsa.debian.org/dep-team/deps/-/merge_requests/7

    The `debian/upstream/metadata` field 'Repository' (e.g. `Repository: https://github.com/eradman/entr.git`) is already used by e.g. `gbp
    clone --add-upstreamvcs` to add the upstream git remote automatically.

    The `gbp.conf` field `upstream-vcs-tag` (e.g. `upstream-vcs-tag = v%(version%~%-)s`) could probably be added as a new upstream metadata
    field if Jelmer and Guido agree on what to call it and how to roll it
    out in a backwards compatible way. This is probably what you were
    referring to as in previous emails some people mentioned that they
    don't want this "generic upstream" information to be defined in a file
    that has the filename of a specific tool.

    The only other field that might be generic is `upstream-signatures`
    for telling if upstream tarballs are expected to have signatures or
    not. No other only field in `gbp.conf` that comes to my mind that
    could be generic. The rest of the `gbp.conf` configs seem very git-buildpackage-specific.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_Plissonneau_Duqu=C@21:1/5 to All on Sun May 18 22:50:02 2025
    Le 2025-05-14 20:52, Otto Kekäläinen a écrit :
    The `gbp.conf` field `upstream-vcs-tag` (e.g. `upstream-vcs-tag = v%(version%~%-)s`) could probably be added as a new upstream metadata
    field if Jelmer and Guido agree on what to call it and how to roll it
    out in a backwards compatible way.
    (...)
    The only other field that might be generic is `upstream-signatures`

    I'm not sure that upstream metadata is the right place for that kind of technical details. It would also be interesting to design this feature
    in a way that could eliminate the need for specific uscan configuration
    in most cases (gbp's upstream configuration strings are probably not
    sufficient for that purpose). Uscan could then be modified to use this
    feature by default, while still allowing more specific configuration
    where needed.

    For the sake of deduplication deprecating the use of Homepage: in source d/control in favor of d/upstream/metadata might also be something worth
    doing; it could eventually be re-added in binary d/control at build time
    from branch d/upstream/metadata, or added by the toolchain to Packages
    indices from either branch or current (latest) upstream metadata.

    Also concerning the Source field in d/copyright, personally I see it as
    the place from where the source was obtained when it was initially
    packaged (and in some cases that might be "the place where the source
    used to be published" which might no longer exist, or might no longer be usable); in other terms what's in this field is primarily there to help checking licensing compliance. In my view it's not meant to be kept
    up-to-date unless there are changes that are relevant for evaluating
    current licensing compliance.

    Cheers,

    --
    Julien Plissonneau Duquène

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sean Whitton@21:1/5 to All on Wed May 21 14:50:01 2025
    Hello,

    On Sun 18 May 2025 at 10:46pm +02, Julien Plissonneau Duquène wrote:

    Also concerning the Source field in d/copyright, personally I see it as the place from where the source was obtained when it was initially packaged (and in some cases that might be "the place where the source used to be published" which might no longer exist, or might no longer be usable); in other terms what's in this field is primarily there to help checking licensing compliance. In my view it's not meant to be kept up-to-date unless there are changes that are relevant for evaluating current licensing compliance.

    It's meant to be kept up-to-date. If it's a dead link, it should be deleted.

    --
    Sean Whitton

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmgtyuEZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQLizD/9RfV7bY9GlQ+kM0pfg8md3 LV3PIgoxxgEzxWVQBEF1AcwGYVGEIlLRC375EdyFCs7dHzz9HT1CMzDN+8CEIQd6 w3BxnT5MJx5NoJD5myC5QX/yYhJU4F69lJ2Z3+iBxjzKHfFIi0eJTijCYLj1eSmk W2E67gYM4wEdSMuhDvvTi8UsnmVG7PKponuLtgeWqzc0XeTwJbU53J/OGiFeAwJT bM6TfKezZZ0dMdTL9qH6VyrOLclazyBTJPSlwr3wBXVuqx7y2Yb6gLpVDDzsVyZC WxPSd+DX+u79hfE+Br+y2QZj0maTMuYblenLOTWncBqz9FwEThjWxTT0juRgSeXH G3hA/4EHbPCcsRPwm95MU3vtrjkF96eYTSE03/0mmO6b52twM16f7dNo/Q8UKiNe uN62MTCbQhMvGsUZYAcfRxetGBxqKDvNJrXvk/0Yhqv/lDzXf+1VnRVcCJzeXuDJ XDGH2qIBwUzdilSWredN0PWlCcovQ889Fr5NhW9qcfRBDnrMMYO/ea7HV8KbRlfV lR28CdYCfbiSsl1CnnfnqniqOQ2QtB/soDz6AlHdyBtawlGkVgu9EeghMUwTztFu rMsh3EcicRtpbU55XDGmRaCL7Ij+ZI7qEUJ48hJOxaNRZRW7VaYdXc0wF6EbvpL8 A7pqqYFpf6hDI/MTYtJmCQ==WWGV
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Us
  • From =?UTF-8?Q?Julien_Plissonneau_Duqu=C@21:1/5 to All on Mon May 26 13:20:01 2025
    Hi,

    Le 2025-05-21 14:45, Sean Whitton a écrit :
    It's meant to be kept up-to-date. If it's a dead link, it should be
    deleted.

    The way it is currently specified in this appendix of Debian Policy [1]
    reads:

    an explanation of where the upstream source came from

    Note "where [it] came from", which has a different meaning than "where
    it could be obtained again".

    I think that it makes sense for the purpose of documenting compliance
    and that there is no need to change this. Some maintainers are replacing
    the dead links by archive.org URIs but personally I don't like the idea
    of mentioning a specific archive service there and would rather keep the
    dead link as it is, eventually just mentioning that it's a dead link
    since <date>.

    There are also cases where upstream projects are split, merged, forked,
    moved ... when a new upstream repository URI (archive or git) doesn't
    offer to download releases that were published on a former one, it might
    be appropriate in some cases to keep both URIs, indicating the latest
    version the former one was used for (e.g. "up to x.y.z: URI").

    Cheers,


    [1]: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#source-field

    --
    Julien Plissonneau Duquène

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sean Whitton@21:1/5 to All on Mon May 26 13:50:01 2025
    Hello,

    On Mon 26 May 2025 at 01:13pm +02, Julien Plissonneau Duquène wrote:

    Hi,

    Le 2025-05-21 14:45, Sean Whitton a écrit :
    It's meant to be kept up-to-date. If it's a dead link, it should be
    deleted.

    The way it is currently specified in this appendix of Debian Policy [1] reads:

    an explanation of where the upstream source came from

    Note "where [it] came from", which has a different meaning than "where it could be obtained again".

    But it refers to the current upstream release, not the one that was
    first packaged.

    --
    Sean Whitton

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmg0VIUZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQJozD/93jr4x5ulSMWHkzdRuZCTd 9vyizh1NkOc3XPqgSphADZ8HEt4M47i1TYWqUD75GSINBWLCgPRjLbh2o70hSkU5 ZOS1PmDjAJzNiEeBOArGfLMfqEcRhScwFKDM361jFFVdf1pHTKF89TB3zRy3x4Rc 7p6sOZHxiNp/bsQYg804E9LKiosMlctOH4l4Oc931/a1kIDCmt7ZwD0ceTCpQBFZ N2L8sYmjlPYOyTksQewCkLhTIl87Ux8UvY2eSFLpRdnxv4a1G8abeR+zN+kaO7bM 6083FUCWPcobRsQxfouMN4tTcBrpPsSWwX6tUjrHNYsfksmvifnCtnxi4R75ecSW dTkSJErUiDwT68/KKrV9rc+qD4JqoIo56JCwRChhe6JFz7ZRi9Grkyeeclcc3rou 4l7YgqqLgGdg/3aZL2hj9e/afy19VdEegFK6jBtm/BpPVe7H0w+pIn/asu6QwvpU Zvr3eGfZmMwdABVilIvo0xnwDo6M+6xl5i15XU6DpKRMvNAwxSIG/IB6gtuCnY0B KalX/GmN1eR/h8Oc/isO3+S3AAKLXg9G1w4VjjMB3j7+WFey0f/6+bLBZnwtvLGr sp9ukYH5fqGOcZ05QBG0QJ2i551ZrqMb28P7c2WCJK/B2RYXD0YqxjOp9WM1ccCr Fb2T+YnC80NnoGF8U9x5GQ==D+9v
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Us