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

rpmspec default output unexpected #2819

Closed
bracketttc opened this issue Dec 16, 2023 · 2 comments
Closed

rpmspec default output unexpected #2819

bracketttc opened this issue Dec 16, 2023 · 2 comments
Assignees

Comments

@bracketttc
Copy link

In prior versions of rpmspec (4.17 and earlier), rpmspec -q output using a format apparently %{nevra}\n.
In the current version (and in the version of 4.18 in Fedora 35), the output looks like %{nevr}.src\n.
If you specify --queryformat '%{nevra}\n', you get the expected output.

@bracketttc
Copy link
Author

Changed in 82dafa3.

Current source of archsuffixTag():

static int archsuffixTag(Header h, rpmtd td, headerGetFlags hgflags)
{
    const char *a = NULL;
    char * val;


    if (headerIsSource(h)) {
        if (headerIsEntry(h, RPMTAG_NOSOURCE) ||
            headerIsEntry(h, RPMTAG_NOPATCH))
            a = "nosrc";
        else
            a = "src";
    } else {
        a = headerGetString(h, RPMTAG_ARCH);
    }


    if (a)
        val = rstrscat(NULL, ".", a, NULL);
    else
        val = xstrdup("");


    td->type = RPM_STRING_TYPE;
    td->data = val;
    td->count = 1;
    td->flags = RPMTD_ALLOCED;


    return 1;
}

So, I'm guessing that when rpmspec calls this, the Header they're passing in thinks it's a source RPM header which makes a sort of sense programmatically, but it doesn't make sense to me for --rpms, and --builtrpms (which are synonymous with the default query).

@pmatilai
Copy link
Member

That'd be a bug, or rather, a regression. .src is only a valid arch for a source rpm.

So 'rpmspec -q' can never legitimately return an .src arch, but 'rpmspec -q --srpm' must return either src or nosrc.

Thanks for reporting!

@ffesti ffesti self-assigned this Mar 26, 2024
ffesti added a commit to ffesti/rpm that referenced this issue Mar 26, 2024
This fixes a regression that was present since 4.18 that printed them out as
source/nosource packages as the headers are no proper binary packages.
Setting the default query to "%{NEVRA}\n" forces the right output.

Resolves: rpm-software-management#2819
ffesti added a commit to ffesti/rpm that referenced this issue Mar 26, 2024
Avoid packages being detected as srpms erroneously

Resolves: rpm-software-management#2819
ffesti added a commit to ffesti/rpm that referenced this issue Mar 26, 2024
Avoid packages being detected as srpms erroneously

Resolves: rpm-software-management#2819
pmatilai added a commit to pmatilai/rpm that referenced this issue Apr 2, 2024
Contrary to expectations, there's a perfectly logical place to
initialize the source rpm name: initSourceHeader(). This gets called
early enough to let use insert RPMTAG_SOURCERPM right after spec
parse for proper binary package identification in headerIsSource().
The only special case is buildreqs.nosrc.rpm generation that doesn't
follow the normal process, so remember to free the normal name there.

Fixes: rpm-software-management#2819
pmatilai added a commit to pmatilai/rpm that referenced this issue Apr 2, 2024
Contrary to expectations, there's a perfectly logical place to
initialize the source rpm name: initSourceHeader(). This gets called
early enough to let use insert RPMTAG_SOURCERPM right after spec
parse for proper binary package identification in headerIsSource().
The only special case is buildreqs.nosrc.rpm generation that doesn't
follow the normal process, so remember to free the normal name there.

Fixes: rpm-software-management#2819
@ffesti ffesti closed this as completed in dc47a50 Apr 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants