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)

+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)

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)

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

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)

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