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 2021
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
%{b
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,
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.
>
>
> 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%{
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
