Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 with/without
DistTag.
3) the dbiFindByLabelFoo() reads every package header in Packages (~100Mb),
possibly multiple times, trying various matches. The proper way to perform a
query like this is to create indices for each field and do a join to minimize
the amount of data that must be read. A change to an rpmdb of that magnitude is
highly unlikely.
(aside)
There is also the issues of patterns in queries: a join will not solve that
problem. RPM5 uses a btree with a prefix key to find candidates to retrieve
rather than retrieving every header. But I digress ...
Warning:
My comments here will be deleted within a week: I have negative interest in
participating in a DistTag discussion that I have already had, and already
implemented. Have fun!
--
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/589#issuecomment-437644351___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 definite advantages IMHO trying to use a simple foo:bar:baz scheme rather than adding all sorts of ornamentation and forbidding characters in intervening fields. YMMV, have at, if the PCRE is read from configuration and used for parsing (as in RPM5), all the separators can (at least in principle) be changed to taste without changing code. Another possible way to fix the error is to limit DistTag to a known reserved key word set or form and changing the PCRE. The key issue is having a EVRD parser that never errors: unrolling the stack from EVRD parsing just isn't going to happen, and rpm has too much state to manage to just exit. In most cases the user will just receive a weird error and exit with a message if the ambiguity you point out is ever encountered. Supplying more fields also avoids the ambiguity. -- 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/589#issuecomment-437643494___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437639456___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 missing/unspecified values are interpreted as matching any value. But I can definitely foresee a need to query all packages with a given DistTag which would become Rpm --query -- --:D The ugly syntax can be hidden in various ways: what is important is that the underlying parser is fed a well formed unambiguous query string which can be matched against existing NEVRDA package identifiers with possible missing values to retrieve a set of packages of interest. -- 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/589#issuecomment-437639173___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
@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 The last dash is the separator between V-R, the 2nd to last dash is the separator between N and the rest. None of V or R or D or A may include a dash. Arch parsing can be handled with a period, followed by key words like "i686" or "x86_64". What remains is EVRD which must be parsed unambiguously whatever separator characters are used, including unspecified or missing values. Epoch is a digit string up to the first colon, D (as in the PCRE) is whatever follows the last colon (and colon is a forbidden character in the D string). The PCRE breaks the EVRD string into substrings assigned to known match indices while also handling missing/unspecified matches. -- 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/589#issuecomment-437638429___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 %evr_tuple_match. Both PCRE's as
written assume a ':' separator for both Epoch and DistTag. One can change the
PCRE to use a '.' or '-' or '/' or whatever character one wishes to separate
the serial representation of the tuple {E,V,R,D} (or T if twiddle-in-version is
desired) that is desired.
So far no one has mentioned the added SuSE inspired twiddle-in-version parsing
that is also necessary to handle in dependency strings if DistTag is handled.
All of the pseudo-regexes mentioned in this issue are incomplete. The PCRE I
have pointed out can be used with pcregrep to do try-and-see experimentation
with various representations of EVR if DistTag is added.
--
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/589#issuecomment-437637165___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437635866___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
@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 --install/-i, which is most definitely used by kernels, and promises never to erase any file or package. Kernel installs are special: the root problem is semantic confusion between "install" and "upgrade" as separate modes. The distinction (like --addsign/--resign) is too subtle for most users and should be coalesced by making --install and --update behave identically (pleasing most users) and devising a means to preserve kernel install behavior. There is no point to a package specified DistTag related tracking dependency imho. And there is little reason (other than the reasoning I supplied above) for DistTag to be drilled throughout package dependencies. Similarly (but too late to change), there was little reason to drill Arch into package dependencies (coloring would have sufficed), but WYSIWYG and the RFE to add DistTag to file naming, and within version comparison, is entirely predictable. Been there, done that, wrto DistTag 9y ago ... *yawn* -- 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/589#issuecomment-437634249___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle DistTag (#594)
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 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/pull/594#issuecomment-437503952___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Handle DistTag (#594)
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 compared first, or last, or ignored. One also has to worry about mixed mode comparisons, like EVR compared to EVRD (or DEVR), etc. Adding a rpmlib(...) tracing dependency for disttag has multiple problems, not the least of which is that a package rebuild is needed to add/remove a disttag tracking dependency. -- 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/pull/594#issuecomment-437487188___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Document --noverify in the man page (RhBug:1646458) (c4f285c)
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 it on GitHub: https://github.com/rpm-software-management/rpm/commit/c4f285cff8f830447857e52848ecf909cedb192a#commitcomment-31224068___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Rename parseBuildInstallClean() to something more generic (d6c4fff)
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: https://github.com/rpm-software-management/rpm/commit/d6c4fff2029d7996389d40047fb1893edcf7fdd5#commitcomment-31194485___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: don't prevealuate lua macros (#556)
@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 run in the same globally persistent environment. That is/was actually the intended feature so that variables in the lua context could be shared/passed between, say, %pre and %post scriptlets implemented using embedded lua. -- 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/556#issuecomment-426220110___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: set builsubdir to the *first* extracted archive not the last one (#551)
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 names, choose whatever directory hierarchy you wish, and script up your "chained builds" in whatever programming language you choose. Then run your "chained builds" within an rpm spec file. -- 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/551#issuecomment-425629385___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: set builsubdir to the *first* extracted archive not the last one (#551)
@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 easy to explain The example I just gave is trivial to explain 3. It is patch and preparation friendly Depends entirely on your POV. Rpm was intended for simple packages that can be independently upgraded. Rather than trying to do a complex "chained" (actually serial unpacking, not chained builds) build, history has shown that decomposing into smaller pieces that are simpler to upgrade is quite efficient, more efficient than "make world" type builds. 4. it is spec maintenance friendly The most often reported problem with spec maintenance these days is the cost of editing thousands of spec files, not how easy it is to "maintain" spec files. While it is certainly easy to delete lines Han it is to, say, change a macro value by editing, the drudgery of changing hundreds or thousands of files in order to conform to some Newer! Better! Bestest! Syntax or policy. -- 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/551#issuecomment-425590288___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
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 %define,
because macro files permit escaped new lines.
Second: if you don't want getopt(3) processing, then simply do not use a
parameterized macro, and arrange for whatever helper you wish to execute to
appear at the end of whatever expansion is attempted.
Third: your suggestion of the definition is at least a reasonable proposal. atm
the string is exactly what getopt(3) expects, nothing more nor less.
Parameterized macros cannot handle long options because getopt(3) cannot handle
long options. And if the options/args are not parsed, then constructs like %*
or %** are just "I want a pony" wishes.
Fourth: parameterized macros are not functions, nor is macro expansion anything
more than recursive string substitution on mild steroids. If you have real
programming needs, then use a real programming language like shell, Python,
etc, instead of honking at length about rpm deficiencies.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/547#issuecomment-425251334___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: set builsubdir to the *first* extracted archive not the last one (#551)
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. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/551#issuecomment-425181164___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
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 need to be included or appropriately defaulted. Devise a syntax for what you are requesting if you wish this RFE implemented. Or supply some reasonable usage case instead of just complaining. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/547#issuecomment-425125507___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: set builsubdir to the *first* extracted archive not the last one (#551)
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 than the few lines of shell script that %setup generates to simplify packaging. Sure times have changed since last century: but surely you are not going to question that the dominant paradigm everywhere is a single tar ball, downloaded, and packaged, where %setup is quite adequate to do the job. Third, bringing up issues like how URL's are represented in a SourceN: directive, and the parsing quirks in rpmbuild, has nothing whatsoever to do with %setup. RPM is not used as a downloader in production at any time this century. Nor is there any code in rpm-4.14 that can parse a URL: a string is passed to curl (or wget) which does the job, nothing more. Fourth, positing that %setup should work as "people expect it to work" is pure sophistry. Packagers expect %setup to do what it has always done, across 25 years of spec files and packaging. Every change to RPM has a huge ripple effect, the rate of adoption of any change is measured in years or decades, because of promises of long term support in enterprise distro's like RHEL and CentOS. If you claim otherwise, or think it's time for a change, then by all means get off your bully pulpit and Show me (and all of us) your code. -- 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/551#issuecomment-424936766___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Purge %_buildshell default. (#550)
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 macros or values you wish to eliminate. -- 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/pull/550#issuecomment-424793992___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: set builsubdir to the *first* extracted archive not the last one (#551)
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 becomes even more complex and counter intuitive because the behavior then starts to be convolved with how a spec file is written, or how rpmbuild is invoked. And %setup then starts to diverge from documented 20yo behavior. (aside) I recommend these solutions merely to shut you up and watch this RFE be closed: I'm tired of your pontifications about rpm's unfriendly user behavior that do not include PR's. -- 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/551#issuecomment-424182018___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: set builsubdir to the *first* extracted archive not the last one (#551)
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 toggle, but let's not go there) a read only flag. The '.' is not part of the name, is stripped off to set a read only flag. Any attempt to redefine the macro value is ignored (and warned iirc). The entire implementation is a couple dozen lines of code. Adding another configurable macro to define whether _buildsubdir or its read only variant with a '.' prefix is to be used can be configured in rpm in multiple ways. The read only variant will of course be the first, rather than the last, value defined by %setup, entirely satisfying the RFE stated herein. -- 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/551#issuecomment-424180043___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: set builsubdir to the *first* extracted archive not the last one (#551)
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. Meanwhile you critiquing an implementation 20y later in multiple RFE's because it doesn't fit your obscure usage case isn't helpful either. If %setup is not appropriate for whatever you are attempting, then DO NOT USE %setup It's really that simple. -- 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/551#issuecomment-424135436___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: set builsubdir to the *first* extracted archive not the last one (#551)
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, or even not using %setup at all, and writing the simple shell commands to unpack archives however you wish, rather than complaining about the (known since last century) Byzantine behavior of %setup -- 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/551#issuecomment-423827616___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Provide macronized default option(s) for %setup (#549)
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. -- 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/549#issuecomment-423759154___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 'rpm -qlv' does not correctly handle long owner and group name (#544)
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 GitHub: https://github.com/rpm-software-management/rpm/issues/544#issuecomment-423696843___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 'rpm -qlv' does not correctly handle long owner and group name (#544)
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 GitHub: https://github.com/rpm-software-management/rpm/issues/544#issuecomment-423696839___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
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 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/547#issuecomment-423695173___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: useful lua errors (#545)
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 for what might be implemented in rpm to simplify your debugging needs. -- 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/545#issuecomment-423694462___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: access to multivalued flags (#546)
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 GitHub: https://github.com/rpm-software-management/rpm/issues/546#issuecomment-423693873___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Provide option for %setup to strip path parts in tarballs (#548)
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 directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/548#issuecomment-423693501___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Provide option for %setup to strip path parts in tarballs (#548)
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 were changed in patch(1) a long time ago. And %patch does not permit specifying the myriad incompatible options of multiple incompatible decompressors that did not exist last century. But forget changing %patch, replace with a new and different macro that does whatever you wish. -- 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/548#issuecomment-423692968___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %requires_eq breaks building in non-English locale (#541)
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: https://github.com/rpm-software-management/rpm/issues/541#issuecomment-423311576___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %requires_eq breaks building in non-English locale (#541)
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 mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] add support for scriptlet deps in generated deps
> 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 the package containing /sbin/ /sbin/install-info >> 2) plus manual %post or %posttrans calling install-info >> >> This was a manual process, so it was sometimes missed in some pkgs. > > > That's why Fedora switched to transfiletrigger. It is much better ;) But we still need the pkgs container the info files to require the needed /sbin/info-install >> We've replaced those manual requires+scriptlets by a filetrigger. >> But we still want info-install to be installed, so in order to replace >> the manual requires, we want to automatically emit the requires on >> info-install >> But we don't want to emit "requires: info-install", >> what we want really is "requires(posttrans): info-install" >> >> The patch enables to emit requires for scriptlets or filetriggers. > > > This is too specific use case I think.. That's an example but there could be more >>> >>> I think the idea usually is that the file trigger would not fire if >>> the package isn't installed, so forcing a dependency here means that >>> there was no benefit to separating it out to be run only when it was >>> needed. It basically makes it impossible to avoid running the trigger. >> Which is exactly the point here: >> Again, here the policy was for all those pkgs to require info-install >> & run it in %post or %posttrans >> In order to ease packager work, we replaced this manual work by using >> a filetrigger. >> But we stil want info-isntall to be installed, hence this patch >>> In the case of info, there's no point in running the info commands if >>> info itself is not installed. You can't use them anyway. :) >> Again, info-install was manually required before, we just want to automate >> that. > > But you don't need scriptlet context dependecies for that. > > There's actually a more generic issue behind this: content viewer > applications. You'll want an info-viewer for texinfo pages, a man page viewer > for man pages, a browser for html content etc. > > I've occasionally played with the idea of generating viewer(mimetype) style > dependencies. Traditionally no such dependencies have been generated because > it is a bit dubious - "every system will have man installed", right, and same > for "info"? And if not then maybe it's for a reason, such as wanting a > minimal disk usage and install was done with --nodocs, in which case dragging > the viewer in would be highly counter-productive. It should be a soft > dependency if anything at all. > > Info only differs from man in that there's a central registry that needs > updating, but that does bring up an interesting question: there are multiple > alternative viewer applications but only install-info from info itself can > maintain the registry. So where does the dependency on the package containing > the trigger script (and install-info) belong? > > After a bit of thought over lunch, I think it actually belongs in the > viewers: as long as nobody wants to view those info files, there's no need to > maintain the registry. Once you install a viewer, that changes. But as long > as the viewers drag in the package with the trigger (so in this case "info"), > the trigger will run on the viewer installation and register all the files > already on disk. > Here's a minority, contrarian POV: Running cache/index rebuilds -- ldconfig, fonts, XML, etc -- should be implemented in rpm, implemented through a different mechanism than triggers. Too much time and effort has been spent arranging dependencies and mechanisms in packaging for what is ultimately simple and obvious tasks. With multiple (3 if you include rpm5) file trigger implementations, designing a common representation and mechanism is almost impossible. *shrug* 73 de Jeff >- Panu - > ___ > Rpm-maint mailing list > Rpm-maint@lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-maint ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: make source less special (#539)
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 thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/539#issuecomment-419795210___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Test [Dependency generation] fails on Fedora Rawhide due to fakechroot problem (#511)
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 replacement for fakechroot. -- 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/511#issuecomment-418570116___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
@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) -- 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/pull/536#issuecomment-417888190___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
> 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 not matter, as long as it is in the > past. Some people always set it to 1 (aka 1970-01-01 00:00:01) and are happy. > If $SOURCE_DATE_EPOCH "does not matter", then any value will do, including a high precision BUILDTIME tag from the *.src.rpm clamped on all files in packaging. Distinct advantages to using a high precision build time everywhere include: * many package rebuilds could be checked for reproducibility without using diffoscope * clamped file mtimes become more compressible! including in metadata with zchunk. * the file mtime tag becomes largely vestigial. * the BUILDTIME becomes useful as a package identifier everywhere, including rebuilds. While some of these issues are out of scope for your definition of reproducibility, all of the advantages above are closely related to some definition of reproducibility. The changelog time parsing is/was deliberately sloppy, where 12 noon stood the greatest chance of not causing a date change if/when the timezone was set incorrectly. Many build systems, and most end-user rebuilds, start from a src.rpm, not from a spec file because the SRPM contains all (at last by design if not in fact) necessary elements for a reproducible build. POSIX routines to parse date/time are now widely deployed: not true last century. There comes a time for improving rpm code rather than zombie marching ancient features into the future forevermore: legacy compatibility can be handled with an opt in or out logic to permit distributions the necessary decades to discuss and change as they wish. > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or mute the thread. -- 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/pull/536#issuecomment-417882743___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
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 all defends on how "reproducibility" is defined: if the definition of "reproducibility" includes file mtimes, well, one MUST change the file mtimes everywhere in packaging to achieve "reproducibility". It would be nice if the so far independent efforts to set time stamps from recipes and have digest plaintext exclude per-build specific information somehow started to unify to a single useful approach. -- 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/pull/536#issuecomment-417822837___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
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 since it depends on conversions with time zone. Try changing the day-of-week in the spec file %changelog to something incorrect, then display the changelog time stamp in the produced packages. Merges through git are also not handled sufficiently well: earlier time stamps can merge before later (which used to cause rpmbuild to fail, dunno current behavior). The entire idea of "reproducibility" as a means to set an arbitrary time everywhere is somewhat suspect. The BUILDTIME has been used as a tie breaker with identical NEVRA in order to prefer one of several packages, based on the same heuristic that depsolvers use, that the "newer" NEVRA (or BUILDTIME) is preferred. Reproducibility with buildids (I.e. digests) is a better overall approach. JMHO, YMMV, everyone's does. -- 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/pull/536#issuecomment-417821833___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
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 it on GitHub: https://github.com/rpm-software-management/rpm/pull/536#issuecomment-417819587___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %setup -T -a 0 -a 1 doesn't extract %{S:0} (#462)
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.
However rpm maintainers do not wish to expose the fact that macro values are
indeed stacks just in case there is a need to change macro expansions to
support arrays in some TBD fashion.
--
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/462#issuecomment-417065605___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %setup -T -a 0 -a 1 doesn't extract %{S:0} (#462)
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 read the appendix that fully documents the %setup options, there is an invocation of %setup that handles (by writing some shell commands) all known usage cases: 20+ years of useful packaging shows that even if you consider the implementation clunky and obscure and poorly documented (as I do). There are several design flaws in %setup, the one exposed here is that parameterized macro functions, implemented using getopt(3), cannot handle multiple identical position sensitive option values. Reimplementing parameterized macros using POPT, which can handle multiple option values unlike getopt(3), and adding a means to handle named macro tuples, to write some perfectly obvious and utterly trivial shell commands can be attempted. Meanwhile: why bother? The rpm macro implementation is receiving an increasing number of bug reports, and useful extensions to automating checkouts with multiple VCS systems are hardly used. Rewrite the whole mess if %autosetup's inability to handle multiple option values is deemed a show stopper sine qua non. Or don't use %autosetup because it's known to be broken. Or document the deficiency (though it's not at all clear where the %autosetup deficiency should be documented). Or live with the flaw and complain mightily that "RPM sucks because ..." every other year or so, maintaining the status quo of open source development. *shrug* -- 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/462#issuecomment-417054319___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM must kill all childs on exit (from section?) (#134)
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 kill all children on exit to see why this RFE against rpmbuild is bad craziness. All of systemd/mock/Koji are much better positioned to determine the runtime environment in which rpmbuild runs than rpmbuild is. Alternatively writing a wrapper (essentially what is already in systemd-run) that invokes rpmbuild and kills all children is entirely feasible. -- 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/134#issuecomment-417002520___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %setup -T -a 0 -a 1 doesn't extract %{S:0} (#462)
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 non-existence of glue macros and using %error. Bullet-proofing failure modes through multiple layers of templating macros and shell and utilities is far beyond the functionality implemented through macro expansions for very little gain in usability. -- 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/462#issuecomment-416991361___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Skip showing Group in output of `rpm -qi` (#534)
@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 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/534#issuecomment-416641791___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Skip showing Group in output of `rpm -qi` (#534)
@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: https://github.com/rpm-software-management/rpm/issues/534#issuecomment-416353966___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Skip showing Group in output of `rpm -qi` (#534)
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 Group taxonomy can be changed, or so that multiple taxonomies organized by Group can be supported simultaneously. Readding support for the Group tag in packages within rpm libraries for alternative depsolver usage 15+ years later without addressing better implementations is a monumental mistake. -- 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/534#issuecomment-416218791___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] RFC: RPMTAG_IDENTITY (whitelist filter)
> 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, > suse etc. > If you are seriously considering supporting per-vendor definitions of IDENTITY plaintext content, then I suggest you take a look at how UUIDv3 and UUIDv5 are calculated to add a global naming authority (I.e. an XQuery URL). I would also suggest using a document generated by headerFormat(), rather than compiling identity markers for tags into rpm, as the plaintext so that the definition of the plaintext used in IDENTITY for various vendors can easily be distributed and maintained outside of rpm. All versions of rpm support --queryformat, and external CLI tools can be used to verify an RPM+UUID implementation (assuming you wish RPM itself to compute IDENTITY as a goal). hth 73 de Jeff ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] RFC: RPMTAG_IDENTITY (whitelist filter)
> 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@:
>
> "The members (and ordering) of the IDENTITY tag set might also
> need to be configurable without recompiling."
>
> Currently I have no idea what is better way to do that. May be one of
> solution can be to define some macro that contains tag that should be in
> calculation, but this doest seem to be convenient and practical.
>
> 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,
> suse etc.
>
You might wish to read this thread to understand the complexities involved in
maintaining plaintext that is reduced to a single value using a hash:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/YOYJEKGZ3N4Q67TVOQ6MHBK37RESBVAQ/
The thread is about (essentially) an IDENTITY-like computation of installed
packages, the discussion is about which representation of the tuple {N,E,V,R,A}
is "best".
> While here is marker for tags that values should be involve to identity
> calculation, I think here should be special case for some of string
> array tags: a marker for processing array before calculation. For
> example, we want to filter some of value from package provides but we
> don't want to exclude the whole array from identity calculation. I think
> it could be done with one more marker with argument of array processing
> function that return (char *) — the result of string processing. There
> is difficulty that RPMTAG_PROVIDE* is three separate tags and I have no
> idea how to take it in consideration.
>
One way to reduce the triple of tags used for dependencies into a single value
to be added to IDENTITY is to convert to a string by using headerFormat. See
what rpm does with queries like --provides.
> About patches: they are RFC, 0002 is mostly draft: there are obviously
> marked more than needed tags. I forgot to enhance commit message for
> 0003, so I'll do it in the next iteration.
>
> Please comment.
73 de Jeff
> [1] http://lists.rpm.org/pipermail/rpm-maint/2018-April/007725.html
> [2] http://lists.rpm.org/pipermail/rpm-maint/2018-April/007721.html
>
>
> ___
> Rpm-maint mailing list
> Rpm-maint@lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-maint
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Skip showing empty Relocations line in rpm -qi (#532)
@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 instead of more modern and easier to change mechanisms like yum groups are an impediment to progress. The issues run far far deeper than optionally displaying tags from packages with rpm --info -- 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/pull/532#issuecomment-415444775___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Skip showing empty Relocations line in rpm -qi (#532)
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 depsolver metadata. It's not just the use of valuable real estate with rpm --info. -- 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/pull/532#issuecomment-415437813___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Skip showing empty Relocations line in rpm -qi (#532)
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 made persistent, and propagated from old to new header during upgrade, then the implementation becomes useful. For extra credit, one might relocate file dependencies as well. -- 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/pull/532#issuecomment-415429707___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %setup -T -a 0 -a 1 doesn't extract %{S:0} (#462)
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: https://github.com/rpm-software-management/rpm/issues/462#issuecomment-415420832___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFC: What approach to improving performance through threads or non-blocking I/O is acceptable in RPM? (#517)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: run rpm scripts on a different thread using MQTT pub/sub message queues (#519)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] BUG: rpmpopt.in has aliases for --httpport that do nothing useful (#525)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] BUG: macros.in has comments about database configuration that no longer apply even to BDB (#526)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] BUG: rpmpopt.in execs of rpmsign are insufficiently complete for legacy compatibility (#527)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFC: use rpmgi consistently with all rpm modes/helpers (#529)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFC: save existing files before replacing, restore original on %post (or other) failure (#531)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] SECURITY: applications use rpm to access the userid, but rpm does not verify binding signatures (#528)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] BUG: macros.in should supply a better suggested key server than pgp.mit.edu (#530)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: rpm --import no longer permits importing GPG pubkeys from SKS key servers (#523)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: macros.in documents http/ftp proxy host/port configuration (#522)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: bringing LMDB out of experimental state (#520)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: rpmbuild --root should undertake similar operations to rpm --root running scripts (#510)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFC: add support for message queues to rpmbuild (#509)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] FYI: RPM+BDB using the CDB model appears to have a race condition (#507)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: teach rpm to supply a backtrace when exiting abnormally (#493)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: use exceptions within macro expansion to deliver errors out of band (#495)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: rpm needs two i18n domains, one for executables, the other for libraries (#505)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add explicit file dependency on the elf loader to use if not implied by glibc libc.so.6 dependency (#489)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: display *.rpm queries in install order (#481)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: permit query formats to be read from @file (#476)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFC: permit erasures to be mixed into install/upgrade transactions (#475)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] BUG: $1 and $2 arguments passed to scriptlets go awry for renamed package upgrades (#474)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add %prep/%build/%install scriptlets to SRPM headers (#467)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add macros used during a build to SRPM header (#466)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: implement configurable policy for features used in packages (#460)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add a way to access the installed NVRA and install time without accessing an rpmdb (#459)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: permit HMAC-XXX for digest XXX (#455)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: differentiate file and directory dependencies using a trailing '/' (#439)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Permit applications to append tags to headers simply (#432)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: make rpm object ref counting atomic (#430)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: rpm should permit a means to add arbitrary tags to packages (#413)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Permit %load/%expand recursive expansion while reading a macrofile (#410)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: the macro test-for-existence %{?...} does not scope directly across builtins (#409)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: file triggers should be path component only. (#412)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM backend performance is limited by arrays of hdrNum's (#290)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM+NDB should implement ndb_dump/ndb_load/ndb_stat for database dumps. (#289)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM+NDB doesn't implement ndb_SetFsync() (#288)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Adding header tag formats to generate UUIDS (#269)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Adding namespaces for macros (#246)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Retrofitting a format version on *.rpm packaging. (#172)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: handle lists/tuples within macro expansions (#503)
@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 thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/503#issuecomment-414514773___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make sure all dependencies for scriptlet are installed before executing them (#436)
@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 stone. The original intent was to use setup to populate /etc/passwd before filesystem in a chroot so that unusual ownership (I.e. not root:root) of directories/files might be undertaken without a warning message from rpm. The issues involved in getting owners correct in rpm before name services were functional was worked around by hard wiring certain common lookups in rpm itself. -- 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/436#issuecomment-414457108___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFC: please reopen issue #458: the checkin you cited is not present in the github browsable code (#514)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: rpm --import no longer permits importing GPG pubkeys from SKS key servers (#523)
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: https://github.com/rpm-software-management/rpm/issues/523#issuecomment-414445317___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
