Miro Hrončok kirjoitti 9.3.2023 klo 13.17:
On 09. 03. 23 10:05, Otto Liljalaakso wrote:
> Miro Hrončok kirjoitti 8.3.2023 klo 17.29:
>>
>> However, maybe it does not work as I expected?
>>
>> [python-setuptools (bundles %)]$ fedpkg prep
>> Not downloading already downloaded setuptools-65.5.1.tar.gz
>> Could not execute prep: Could not find the release/dist from branch
>> name bundles
>> Please specify with --release
>
> Right, it looks like you interpreted "outside of an established
> dist-git repository" to cover the case where you do have a Git
> repository, but are in a local branch with a custom name.
> Unfortunately, currently only the case where there is no Git
> repository at all is covered.
Mea culpa. I assumed that's the case because I don't use fedpkg outside
of git much.
> I presume that in your example you intend to eventually create a pull
> request. Fedpkg should have a great support for that as well, but a
> bit (just a bit) more work is needed to cover that case. I suppose
> that it would be enough to, instead of printing the error you saw,
> fall back to using the same default mechanism that is used for the
> no-Git case. I will take a look at some point — unless somebody beats
> me to it, of course.
I took a look at this, and making '--release rawhide' for unknown
branches is very easy [1]. I did not create a pull request yet, because
I am a bit unsure if this is a good idea. My assumption is still that
the vast majority of unknown branches are created for Rawhide pull
requests. But for the ones that are for some other purpose, the default
behavior changes from asking to be explicit with --release, to doing the
wrong thing.
There would be log output notifying about defaulting to 'rawhide', and
the --release parameter could still be used to select the correct
release. So maybe convenience for the majority case weighs more than
some risk for the minority case?
[1]:
https://pagure.io/fork/oturpe/fedpkg/c/712dc656c4b06dafb693e5048baef45a0d...