Re: Release rpkg-1.66 and fedpkg-1.44
On 13. 03. 23 21:53, Otto Liljalaakso wrote:
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?
I think so.
This can even be improved to make f38-foo default to f38 etc. That way, I would
hardly ever need to use --release except for cases where I want to test-build
foo on both rawhide and f38.
If you worry about the risks, I suppose fedpkg build (without --scratch) might
abort without --release when the branch is not "proper". All the other use
cases i could think of should be safe.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok