Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sources in included files are not found #342

Closed
1 of 2 tasks
imphil opened this issue Jan 9, 2024 · 3 comments
Closed
1 of 2 tasks

Sources in included files are not found #342

imphil opened this issue Jan 9, 2024 · 3 comments

Comments

@imphil
Copy link

imphil commented Jan 9, 2024

What happened? What is the problem?

I have spec files that use "%include" to share common parts, like this (in this case, we have "versioned" packages that are co-installable):

# my-name-1.0.spec
%global base_name my-name

Version:        1.0
Name:           %{base_name}-%{version}
Release:        1%{?dist}
Source100:      %{base_name}-common.inc

%include %{SOURCE100}
# my-name-common.inc
Source0:        %{base_name}-%{version}.tar.xz
Summary:        My summary
License:        GPLv3

I then want to get all sources with spec.sources().content

Currently, I only get ["my-name-common.inc"].

#341 has a failing test which shows the problem in executable form.

Workaround

  • There is an existing workaround that can be used until this issue is fixed.

Participation

  • I am willing to submit a pull request for this issue. (Packit team is happy to help!)
@nforro
Copy link
Member

nforro commented Jan 9, 2024

Thanks for reporting this. I see the issue, however, I'm not sure if it is possible to do anything about it. specfile won't be able to edit tags in included files, but I suppose you are interested only in parsing/read-only access, right? If so, I think you should be able to get what you want like this:

from specfile import Specfile
from specfile.sources import Sources

spec = Specfile(...)
for source in Sources(spec.tags(spec.parsed_sections.package).content, []):
    print(source.expanded_location)

@imphil
Copy link
Author

imphil commented Jan 9, 2024

Thanks @nforro, that does the trick! I'm indeed only interested in the parsing part.

Just FYI, since I had both code paths around: specfile is around 5x slower than rpmspec -P and parsing the Source lines from the output. It's not much of a problem for my use case, but maybe good to know.

@imphil imphil closed this as completed Jan 9, 2024
@github-project-automation github-project-automation bot moved this from new to done in Packit Kanban Board Jan 9, 2024
@nforro
Copy link
Member

nforro commented Jan 9, 2024

Just FYI, since I had both code paths around: specfile is around 5x slower than rpmspec -P and parsing the Source lines from the output. It's not much of a problem for my use case, but maybe good to know.

Yes, that's an unfortunate fact. There is still some room for optimization, but due to focus on modification, parsing with specfile will always be slower than rpmspec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

2 participants