I should point out that there are far bigger issues than the separator if
DistTag is incorporated as a package identifier:
1) precedence of comparison: is it EVRD (as is common with %{?dist} usage) or
is it DEVR (as some might wish)
2) interoperability when mixtures of packages are installed
E is always (when present) a digit string followed by a colon. Trying E: first
in a greedy PCRE should resolve the ambiguity between N-E:V and N-V:D for all
but an all digit V string (which is possible but quite rare in the real world,
and easily worked around if encountered.
There are
Most definitely short forms of N, or N-V, or N-V-R, or N.A, or N-E:V, etc are
supported by rpm queries, and not only on the CLI, but also in the API.
Adding DistTag just makes the package identifier retrieval "label" more
complicated.
--
You are receiving this because you are subscribed to
And to be ultra pedantic for parsing a pathological string that has missing N,
E, V, and A but explicit R and D, there would need to be two dashes in front of
"release:disttag" from the rules I just described:
rpm --query -- --R:D
Yes this is a pathological corner case that assumes that
@imz: it's the EVR string in a separate tag, not the NEVR or NEVRA (or variants
including DistTag) identifiers where the parsing complexities (including
missing values) are hidden.
The parsing rules (which you mentioned) that splits N from the rest (in an
explicit NEVRDA) string is basically
In the interest of moving conversations about what character SHOULD be used as
a separator for DistTag, I point you at the PCRE regex that has been in use for
almost a decade here.
http://rpm5.org/cvs/fileview?f=rpm/macros/macros.in=1.39.2.52
See the 2 (one commented out) definitions of
Nit picky parsing comment:
The representation for "release:distag" (your example) fed to --query MUST be
rpm --query -- -release:distag
Without the leading - on release, a parser will interpret release as version,
doh!
See if you agree ...
--
You are receiving this because you are
@mlschroe: dependencies are a form of "package selection" and so DistTag will
eventually be needed in EVRD or DEVR, just like multilib arch is needed (there
are multiple RFE's and an implementation) to provide the desired specificity.
Presumably the "weird" package refresh mode you refer to is
Colon is a perfectly natural tuple separator widely used: see $PATH for an
obvious example.
This is a parsing, not an aesthetic, issue whatever your opinion might be.
Dependency tuples need to be easily parsed into a {E,V,R,D,...} tuple as simply
and speedily as possible.
--
You are
There are 2 parsing problems triggered by adding disttag:
1) how to represent distag in dependencies (omv used a ':' separator)
2) how to represent distag in package file names (omv used a '-' separator)
There is also the question of precedence in version comparison, whether disttag
should be
Overloading the meaning of "verify" for package, not installed, files is surely
going to confuse users.
See similar history with "conflicts" which confused dependency and file
conflicts.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
build/parseSpec.c:804 has a cut-and-paste error
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@jasontibbitts: %luamacro would need to be implemented as a co-routine because
of rpm's embedded lua interpreter has a persistent global environment.
That is very different than shell code, where a sub-shell inherits but cannot
change its parent's environment. With rpm+lua, all lua invocations
You have chosen rpm spec files and macros for your implementation.
Neither was designed for multiple builds in a single package, nor was rpm for
that matter.
Instead of complaining about rpm deficiencies and quirks, you might wish to
rethink your approach, look at the inputs of archive/patch
@nim-nim:
Your "nice properties" arguments are not persuasive.
Point by point:
1. Simple and easy to understand
For example, the common case of a single well formed compresset tarball with a
patch in a spec file is even simpler than your design:
%prep
%setup
%patch
2. It is simple and
First: use a macro file, not a %define, to hide abc...XYZ. If you must have
package specific macro overrides, the use %{load:...} and bury the override in
a SourceN: directive. The most important reason to use a macrofile is
readability: you can split a definition over multiple lines, unlike a
RPM has no concept of "chain building": there is only one build in the spec
file, and there is only one SRPM.
Please define whatever terms you choose to make up before using so that others
might understand your complaints.
--
You are receiving this because you are subscribed to this thread.
That is indeed the case that some flags are handled by the macro processor,
while others are passed along, when -- is used to stop getopt(3) option
processing.
Long options would need a means to be specified in the macro definition, and
multiple duplicated options, and or arg types, would also
First of all, MaximumRPM was written in 1997, not 2000.
Second, the vast majority of packages have no need for a fancier %setup, nor
enhancements like %autosetup. Most software has been distributed on the
Internet as a tarball that can be downloaded, and most packages do not need
anything more
The values may be the same but the usage cases are not.
The single underscore was intended as the shell for the %build section, while
the double underscore was intended to set defaults for the different build
section sections.
You of course are permitted to do whatever you wish with whatever
Even simpler -- only one line of code needs to change -- would be to define
_buildsubdir only if it is not already defined.
That might even permit overriding _buildsubdir to be set from the spec file, or
-- with Yet Another POPT alias -- from the rpmbuild command line.
And of course %setup
FWIW, here is an implementation that would permit first rather than last
definition of %_buildsubdir to be used under user control.
RPM5 permits read only macros which -- when set -- prevent a macro value from
being changed.
The syntax prefixes a macro name with a '.' in order to set (actually
You are absolutely correct that %setup from time immemorial has been overly
complicated, non-intuitive, and *documented*.
Expecting users to change their behavior 20y later is a political task, better
left to distro packaging committees and package reviews: %setup does what
%setup does.
The %setup macro-in-c was never intended to be used multiple times: see the
shell code generated, and look at the needless unnecessary commands generated
if/when %setup is used multiple times.
You are likely better off (for whatever you are attempting) using %setup once
to set %_buildsubdir,
There are no tar flags that I can think of that might be set globally through
configuration, unlike patch, where kernel packagers in Fedora wished tighter
control of fuzz.
Keeping old files makes sense only if untarring into a populated directory,
almost never the case with rpm builds.
--
FWIW, rpm -qlv used exactly the same format as cpio(1) when implemented way
back when.
Continuing that practice of using the same format as cpio(1) preserves output
compatibility.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
FWIW, rpm -qlv used exactly the same format as cpio(1) when implemented way
back when.
Continuing that practice of using the same format as cpio(1) preserves output
compatibility.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
RPM already has support for %(...) shell diversions and %{lua:...} embedding,
both of which are well known programming paradigms that should be used instead
of macros wherever you find your efforts limited by lack of a failure message
from a macro option/argument.
--
You are receiving this
Expecting rpm to provide trackbacks with appropriate line numbers through
multiple invocations of lua (and shell) is way out of scope for rpm.
Please provide an explicit example of a usage case where your debugging might
have benefitted from better diagnostics, as well as a positive suggestion
Please provide an explicit example usage case that demonstrates the need (or
benefit) of adding long options or multiple position sensitive option/argument
parsing to macros.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Ditto %setup: prototype an entirely different implementation with whatever
improvements you wish to see instead of adding tortured additional syntax to
the existing implementations of %setup and %patch.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Changing %patch creates a bigger legacy compatibility problem than any "fix"
solves.
If you truly think that %patch needs to be improved, the please prototype an
entirely new macro-in-C implementation and add whatever you wish to see.
For starters, %patch in rpm is forced to carry options that
FWIW, %_dbpath should be explicitly passed into the rpm query invocation in
%requres_eq, principle of least surprise.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
And there is no --root with rpmbuild
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/541#issuecomment-423309266___
Rpm-maint
> On Sep 13, 2018, at 7:21 AM, Panu Matilainen wrote:
>
>> On 9/13/18 12:38 PM, Thierry Vignaud wrote:
>> Le mer. 12 sept. 2018 à 19:15, Neal Gompa a écrit :
>> In Mageia, we eg had:
>> 1) manual "requires(post)" or "requires(posttrans): info-install"
>> (info-install being
Yes computing SourceN: spec file directives from %SOURCEN macros is an
unnatural act.
The macros are generated when the directive is parsed and not vice vesa.
Whatever you are requesting (it's not clear) seems odd and unnatural.
--
You are receiving this because you are subscribed to this
Have another flaw reproducer using fakechroot with rpm4 "make check"
0) Create (and use) a symlink to the directory where rpm just built is under
test.
1) Run "make check" in rpm4.
Hint: pseudo from the Yocto Project (written and maintained by Peter Seebach)
is a mature and reliable
@bmwiedemann: you recently made neon "reproducible" and asked about upstream
neon to send a patch.
This link likely has all the essential pointers:
https://github.com/aw/neon-unofficial-mirror
Neon is an ice library even if "old" and DAVFS peculiar (but with a large
following on M$ Windoze)
> On Sep 1, 2018, at 2:04 AM, Bernhard M. Wiedemann
> wrote:
>
> I'm already producing bit-identical RPMs using the 4 macros documented in
> https://en.opensuse.org/openSUSE:Reproducible_Builds
> So no changes on digests or signatures are needed atm.
>
> Inaccuracy of $SOURCE_DATE_EPOCH does
See also the thread on RPMTAG_IDENTITY here on rpm-maint@, which is another
attempt at "reproducibility" (in the sense of reproducible "packaging") that is
perhaps more soundly based because the BUILDTIME and file times are
deliberately excluded rather than being reset to some known time.
But
See issue #197 for how to represent time stamps with nano/micro second
precision in header tags with the least amount of legacy incompatibility.
There is an ISO standard for parsing high precision dates/times that rpm has
never adopted, nor is the %changelog time stamp particularly accurate
The real problem with setting a reproducible build time from a %changelog
entriy is lack of precision in the syntax of the permitted time. Other flaws
will eventually be discovered imho.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
I should point out that multiple identical position sensitive option values end
up as a stack of values even with getopt(3) parsing, and that the stack of
option values could recreate the list of -a values to pass to %setup using the
proposed syntax %{-@a: -a}, thereby fixing this issue.
First of all, there is nothing forcing anyone to use %autosetp, nor anything
preventing anyone from redefining %autosetp to whatever is wished, including
adding better diagnostics.
Meanwhile the flaw is in %setup through over-thinking, a design flaw that goes
back to at least 1997.
If you
None of systemd-nspawn, systemd-run, mock or Koji or (for that matter) bash
have much to do with rpmbuild.
Expecting rpmbuild to solve complex issues involving runtime environment
cleanup is bad craziness.
You might consider -- say -- reporting an RFE to systemd or mock or koji or
bash to
Internalizing %autosetup in order to handle multiple identical position
sensitive options in the already internalized %setup makes little sense: the
goal was to permit users to change templating without recompiling rpm.
Better error messages can certainly be attempted by testing for
@pmatlai: LSB tried to adopt package standards already deployed: GROUP was
mandatory in RPM at the time.
The rpm-3.0.6 format that LSB chose as a standard has been irrelevant since
2002.
Removing GROUP from package content != eliminating GROUP usage entirely.
--
You are receiving this
@jasontibbitts: presumably you meant --queryformat, not POPT, which already can
conditionally test for existence of tags in headers.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Re "... key reason ..."
This is revisionist history without basis in fact by an outsider who was not
present at RedHat
Adding Group by value in package content forces rebuilds to Get It Right!.
The better implementation associates Group values with packages, not within
packages, so that the
> On Aug 22, 2018, at 5:01 PM, Vladimir D. Seleznev
> wrote:
...
>
> Also its value may be needs a prefix for versioning tag value. When new
> tags are marked to be involve to calculating the prefix changes. I think
> the prefix should also include a vendor identifier e.g. fc, alt, mga,
>
> On Aug 22, 2018, at 5:01 PM, Vladimir D. Seleznev
> wrote:
>
> You convinced me that there should be whitelist filter, so I rewrote
> code for it. Follow Panu suggestion [1] I wrote .C generator to filter
> proper rpm tags. But currently it does not allow this suggestion [2] by
> jbj@:
>
>
@Conan-Kudo: non-RedHat based distro's stubborn use of Group: and other
RPM_I18NSTRING_TYPE in spite of alternative implementations that solved real
world problems forces ancient code to be zombie marched into the future
forevermore. Distro's continuing to use Group: tags from rpm packages
Or rip out the entire relocation implementation, leaving only parsing of
Prefix: for legacy spec file syntax compatibility perhaps: the implementation
is almost entirely useless currently because of lack of persistence, and the
difficulty of propagating relocated paths into file triggers and
Relocations in RPM are a vestigial implementation: in fact every path can be
relocated all this century independent of whether there is one or more Prefix:
tags in a spec file.
The existence of one or more Prefix: tags controls whether a warning is
displayed (or not).
If the relocations were
Modern POPT will collect multiple instances of an option in an argv array.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #517.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/517#event-1800135940___
Rpm-maint mailing list
Closed #519.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/519#event-1800134078___
Rpm-maint mailing list
Closed #525.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/525#event-1800124589___
Rpm-maint mailing list
Closed #526.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/526#event-1800123996___
Rpm-maint mailing list
Closed #527.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/527#event-1800123531___
Rpm-maint mailing list
Closed #529.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/529#event-1800063702___
Rpm-maint mailing list
Closed #531.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/531#event-1800063225___
Rpm-maint mailing list
Closed #528.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/528#event-1800057039___
Rpm-maint mailing list
Closed #530.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/530#event-1800057718___
Rpm-maint mailing list
Closed #523.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/523#event-1800055999___
Rpm-maint mailing list
Closed #522.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/522#event-1800055371___
Rpm-maint mailing list
Closed #520.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/520#event-1800054291___
Rpm-maint mailing list
Closed #510.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/510#event-1800052994___
Rpm-maint mailing list
Closed #509.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/509#event-1800052399___
Rpm-maint mailing list
Closed #507.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/507#event-1800051207___
Rpm-maint mailing list
Closed #493.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/493#event-1800049896___
Rpm-maint mailing list
Closed #495.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/495#event-1800050573___
Rpm-maint mailing list
Closed #505.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/505#event-1800047331___
Rpm-maint mailing list
Closed #489.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/489#event-1800042005___
Rpm-maint mailing list
Closed #481.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/481#event-1800041204___
Rpm-maint mailing list
Closed #476.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/476#event-1800040740___
Rpm-maint mailing list
Closed #475.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/475#event-1800040306___
Rpm-maint mailing list
Closed #474.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/474#event-1800039344___
Rpm-maint mailing list
Closed #467.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/467#event-1800038698___
Rpm-maint mailing list
Closed #466.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/466#event-1800038279___
Rpm-maint mailing list
Closed #460.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/460#event-1800037600___
Rpm-maint mailing list
Closed #459.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/459#event-1800036870___
Rpm-maint mailing list
Closed #455.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/455#event-1800035750___
Rpm-maint mailing list
Closed #439.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/439#event-1800034023___
Rpm-maint mailing list
Closed #432.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/432#event-180005___
Rpm-maint mailing list
Closed #430.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/430#event-1800032510___
Rpm-maint mailing list
Closed #413.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/413#event-1800030257___
Rpm-maint mailing list
Closed #410.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/410#event-1800028616___
Rpm-maint mailing list
Closed #409.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/409#event-1800028042___
Rpm-maint mailing list
Closed #412.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/412#event-1800029597___
Rpm-maint mailing list
Closed #290.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/290#event-1800026510___
Rpm-maint mailing list
Closed #289.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/289#event-1800025450___
Rpm-maint mailing list
Closed #288.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/288#event-1800024217___
Rpm-maint mailing list
Closed #269.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/269#event-1800023513___
Rpm-maint mailing list
Closed #246.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/246#event-1800022686___
Rpm-maint mailing list
Closed #172.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/172#event-1800020398___
Rpm-maint mailing list
@Conan-Kudo: we differ on what a serious patch is: both zstd and LMDB were
shooting fish in a barrel.
Give them a bit of a break ... from what? Ignoring issues takes zero effort.
I am not on iirc, it's a waste of time for me.
--
You are receiving this because you are subscribed to this
@cgwalters: re "speaking of dependency loops and scripts"
yes the current state of affairs with setup and filesystem is insane. Those
packages should be combined, and the dependency that drags in filesystem (or
%setup if you prefer that name) as a prerequisite of glibc should be cast into
Closed #514.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/514#event-1798629319___
Rpm-maint mailing list
There are certainly failure modes if firewalls or chroot's prohibit accessing
SKS ports.
That is not a failure of the code in RPM.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
1 - 100 of 693 matches
Mail list logo
