Re: Multiple snapshots and versioning
On Sun, Apr 4, 2021 at 11:19 AM Artur Frenszek-Iwicki
wrote:
>
> I thought about it some more and realised that using just the date allows me
> to stick everything in one package. Basically, the idea is:
>
> %global branch1_date 20210101
> %global branch2_date 20210202
> %global branch3_date 20210303
>
> %global package_date %( bash scriptlet that picks max value from
> %{branchX_date} macros )
> Version: 2.0
> Release: %{package_date}.1%{?dist}
>
> I think this should work fine, while also not breaking the packaging
> guidelines. Thanks for the suggestion.
Wasn't your first problem that you want to have a Release tag that
rpmdev-bumpspec can deal with? I doubt that will be the case with this
format.
Instead, I suggest you switch the "1" (incrementing integer) part and
the %{package_date} part, which also matches the Packaging Guidelines
better, and should not confuse rpmdev-bumpspec.
Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Multiple snapshots and versioning
I thought about it some more and realised that using just the date allows me to
stick everything in one package. Basically, the idea is:
%global branch1_date 20210101
%global branch2_date 20210202
%global branch3_date 20210303
%global package_date %( bash scriptlet that picks max value from
%{branchX_date} macros )
Version: 2.0
Release: %{package_date}.1%{?dist}
I think this should work fine, while also not breaking the packaging
guidelines. Thanks for the suggestion.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Multiple snapshots and versioning
On 29/03/2021 11:32, Fabio Valentini wrote: There are two examples of how to work around this issue: - The ruby package bundles a bunch of gems in addition to the Ruby interpreter, and while some of the gem subpackages have different versions, there's only *one* Release tag in the whole package, and it never gets reset to 0 so the upgrade path for all subpackages works out fine. - The rust package ships the rust compiler and some tools (cargo, rustfmt, rls), and they have different "upstream" versions, but since they are never exposed to the user, these are ignored in Fedora, and just inherit the main version of the package, i.e. the version of the Rust compiler itself. There's also what nodejs does where the npm subpackage has the npm version but the nodejs version and release combined are used as the release for the subpackage, for example: nodejs-14.16.0-1.fc33.x86_64 npm-6.14.11-1.14.16.0.1.fc33.x86_64 That ensures that npm has the "correct" version but also that it will also be upgraded when nodejs upgrades. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Multiple snapshots and versioning
On Sun, Mar 28, 2021 at 6:17 PM Artur Frenszek-Iwicki wrote: > > I'm looking to package some GTK themes. Those themes come in several colour > variants. The author decided on a workflow where, instead of keeping variants > alongside each other in the tree, each variant has its own git branch. > > When working with git snapshots, the packaging guidelines [1] say to put > the snapshot data in the Release: field. This is simple enough when working > with a single "main" source, but what when there's multiple sources? > > A solution could be to put each colour variant into a subpackage, > and make the "main" package a file-less package that just Requires: > all the colour variants. This way, each subpackage can have a different > Release: tag. However, doing this messes with rpmdev-bumpspec, which > gets confused and slaps ".1" at the end of each subpackage's Release: tag, > which in turn makes the Requires: unsatisfiable. AFAIK, having different "Release" tags for subpackages just is not supported well (or at all). There are two examples of how to work around this issue: - The ruby package bundles a bunch of gems in addition to the Ruby interpreter, and while some of the gem subpackages have different versions, there's only *one* Release tag in the whole package, and it never gets reset to 0 so the upgrade path for all subpackages works out fine. - The rust package ships the rust compiler and some tools (cargo, rustfmt, rls), and they have different "upstream" versions, but since they are never exposed to the user, these are ignored in Fedora, and just inherit the main version of the package, i.e. the version of the Rust compiler itself. Maybe you could do something different, i.e. use the %baserelease macro, which should help with rpmdev-bumpspec, at least. But it will still give you the same Release tag for each subpackage. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Multiple snapshots and versioning
> How are version numbers handed upstream?
Upstream did choose a version, but the releases are rather infrequent,
so I'd prefer to use snapshots.
> Would a simple date work for you?
>
> Source1: url-of-branch-1-source
> Source2: url-of-branch-2-source
> ...
>
> Version: 0
> Release: 1.20210329%{?dist}
This could work, but it has a slightly different pitfall -
while rpmdev-bumpspec does properly update the Release: tag
on the subpackages, it does not modify the Requires:,
again rending them unsatisfiable.
In both cases (i.e. your suggestion and my idea) this isn't
a large problem - fixing it would take a minute or two -
but it still means having to do some extra work whenever
Mass Rebuild comes along and all the specs get automatically bumped.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Multiple snapshots and versioning
Artur Frenszek-Iwicki kirjoitti 28.3.2021 klo 19.16:
I'm looking to package some GTK themes. Those themes come in several colour
variants. The author decided on a workflow where, instead of keeping variants
alongside each other in the tree, each variant has its own git branch.
When working with git snapshots, the packaging guidelines [1] say to put
the snapshot data in the Release: field. This is simple enough when working
with a single "main" source, but what when there's multiple sources?
How are version numbers handed upstream? Does each branch have its own
version number, all of them have the same version number, or no version
numbers are assigned at all? Assuming the last, then "Upstream has never
chosen a version" [1] would apply and package Version would be 0.
Regarding the snapinfo part of Release, the guidelines do not actually
require including commit ids for snapshots. Only date string is mandatory:
"All snapshots MUST contain a snapshot information field (:)
in the Release: tag. That field must at minimum consist of the date in
eight-digit MMDD format. The packager MAY include up to 17
characters of additional information after the date."
Would a simple date work for you?
Source1: url-of-branch-1-source
Source2: url-of-branch-2-source
...
Version: 0
Release: 1.20210329%{?dist}
[1]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_upstream_has_never_chosen_a_version
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Multiple snapshots and versioning
I'm looking to package some GTK themes. Those themes come in several colour variants. The author decided on a workflow where, instead of keeping variants alongside each other in the tree, each variant has its own git branch. When working with git snapshots, the packaging guidelines [1] say to put the snapshot data in the Release: field. This is simple enough when working with a single "main" source, but what when there's multiple sources? A solution could be to put each colour variant into a subpackage, and make the "main" package a file-less package that just Requires: all the colour variants. This way, each subpackage can have a different Release: tag. However, doing this messes with rpmdev-bumpspec, which gets confused and slaps ".1" at the end of each subpackage's Release: tag, which in turn makes the Requires: unsatisfiable. I could, alternatively, put the snapshot data in each subpackage's Version: tag, but this goes against the Guidelines. I could also just pretend that there's only one source, ship everything as one package, and only use the snapshot info for the "main" branch. Though this is a rather inelegant approach. So, I guess my question is: what would be the preferred approach? [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
