rpkg

#690 `Commands.layout` attribute not updating correctly
Opened by nikromen. Modified

Open
Close Issue

Hello,

When using the Commands.upload method in Copr, we're getting the rpkgError: Spec file is not available error, even though the spec file is present. I believe the issue stems from the Commands.layout attribute not updating correctly.

Here's what's happening (We're using our own method import_package for importing packages):

  • We initialize the Commands class right at the beginning with an empty directory.

    • At this point Command class has Commands.layout attribute that checks the empty directory at this moment and correctly sets IncompleteLayout.

  • Later we initialize git in this directory and call import_srpm method to import the desired files, including spec file. However, the Commands.layout attribute remains unchanged as IncompleteLayout, leading to the upload method failing.

I understand this isn't an issue with fedpkg since users call these commands separately, so the layout is up-to-date. However, we use the rpkg API directly. This means that we'd have to initialize a fresh Commands class after each command is called or update the layout by ourselves, which isn't ideal.

Can you suggest a solution to resolve this issue? Perhaps a method in the API that allows refreshing layout or some logic that automatically updates it? Or maybe we're misunderstanding the rpkg API and should be using it differently?

This is getting a bit overcomplicated, an ugly work-around:
https://github.com/fedora-copr/copr/pull/2686/commits/81eabfb7c9069b20aaae121433a50d3f38ad341e

Commands class is not re-usable for sub-sequent command calls. Is this per design?
How expensive would be to fix this in rpkg lib? How expensive would be to cut-out the corresponding logic for importing srpms, and drop rpkg dep?

Hi, after fixing the issue here
https://pagure.io/rpkg/pull-request/691

your copr code should start working the old way - that means without re-initialization of the Commands object. Could you, please, confirm it?
The fix is included in the rpkg-1.66-7 build.

hi @onosek sorry for late reply, I was on sick leave

the issue is still present :/ because of this -
https://pagure.io/rpkg/c/d2c63c32306732695b7fe5f9dda3deecb7899f4f?branch=master

because uses_rpmautospec and later load_rpmautospec expect some path in self.layout.specdir here https://pagure.io/rpkg/blob/ad67fa9069befef3e4ba5180eea6bf56b658e664/f/pyrpkg/init.py#_695 so the reinitialization is still needed to refresh layout.

In my opinion, more bugs like this may occur in the future even until the refresh of the layout is resolved because there may be added a new code that uses the layout and expects an actual path - not None value

I prepared a fix that potentially solves the issue:
https://bodhi.fedoraproject.org/updates/?search=rpkg-1.66-8
Edited by onosek

Hi @onosek , thanks for the fix, sorry for the long delay (again :( ), I was on long PTO :)

Yep this will work, but my concern above is still present :/ Whenever some new feature will be added that counts with a fresh layout, it will fail again. So this fix is rather correcting the consequence, not the cause.

There's still the API usability issue we had to work-around by this commit:
https://github.com/fedora-copr/copr/commit/41bfa6d14c0060a6b9bab0be8ddd6caccedc57dc

We can not use the object instantiated from Commands class, and we have to re-initialize the object.

So I don't think 1.66-8 actually fixes the problem.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.