I also don't have too strong of an opinion on that. Only the comment that most
build systems may be pretty surprised if suddenly packages from more than one
build arch show up. May be we should keep things as they are and just clean up
the code.
--
Reply to this email directly or view it on
Replace mktree.fedora with mktree.podman for local use as well. Please see the
commit messages for details.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2733
-- Commit Summary --
* Add --shell command to rpmtests
Closed #2691.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2691#event-10753425349
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Superseded by #2733.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2691#issuecomment-1777132805
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
Yeah, giving the packager more control here is something we generally want. The
dependency generators are a bit clunky as soon as they don't exactly what one
wants/needs.
--
Reply to this email directly or view it on GitHub:
Improved wording of the commit message
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2732#issuecomment-1777100699
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2603 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2603#event-10752520725
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Guess not. Feel free to re-open if we missed something and there is really
something that needs doing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2603#issuecomment-1777011289
You are receiving this because you are subscribed to
While there is no generally agreed standard for this we should at least use
only one. Comma separated lists are commonly used. Lets just pick *italic*
for man pages.
Thanks to Frank Dana https://github.com/ferdnyc; for pointing this out.
Resolves: #2731
You can view, comment on, or merge this
OK, fixed a few typos and thinkos in the commit messages :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2733#issuecomment-1777226729
You are receiving this because you are subscribed to this thread.
Message ID:
> That's why I said you'd need to supply all the desired files yourself when
> using this CLI option as there's no way to just prepend/append paths to it.
Just to illustrate better how one could use this (in order to achieve your
original objective):
```
# dnf install --releasever=38
I have to say, there's beauty to the simplicity of this. Would be even simpler
if the new generator was added as the last thing to the array I think.
Subject to name-bikeshedding of course. "local_generator" is not a bad for what
it is, but my head keeps coming up with spec_somethings instead
This generator can be used by .spec file, which ships their own generators:
~~~
Source1: generator.req
%global __local_generator_requires bash %{SOURCE1}
~~~
Resolves #782
You can view, comment on, or merge this pull request online at:
> When we talk about configuration, what's meant by that? All macro
> definitions? Because there **only** seems to be an issue with
> `/etc/rpm/macros.image-language-conf` like things.
Yeah, apologies for the confusion. Even though a lot of RPM "configuration" is
done through macros, RPM does
> I have to say, there's beauty to the simplicity of this. Would be even
> simpler if the new generator was added as the last thing to the array I think.
That is an option. Will look at it tomorrow
> Subject to name-bikeshedding of course. "local_generator" is not a bad for
> what it is, but
> > Subject to name-bikeshedding of course. "local_generator" is not a bad for
> > what it is, but my head keeps coming up with spec_somethings instead (and
> > then rejecting)
>
> This is the hardest think, right :(
And that is why I have also considered the `find` name, which was already
16 matches
Mail list logo
