IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
%EVR was introduced to be used in spec-files for intersubpackage
(strict) dependencies.
What if we write (when substituting %%EVR) E:V-R:D into dependencies
instead of the previously written E:V-R? Will the interpretation of
these dependencies by rpm change (when installing packages) in a good
or bad way in any cases?
The "dependencies" can be Requires, Conflicts, Obsoletes.
rpm-build already produces packages which include disttags (D), and
Provides in the form of E:V-R:D, and strict intersubpackage
dependencies of such form (Requires; generated automatically).
Intersubpackage Requires in the form "< %EVR" or "> %EVR" don't make
sense. So, the interesting cases this change can affect are:
* Conflicts of the form "< %EVR" or "> %EVR" or "= %EVR" (the last one
must be quite rare);
* Obsoletes of the form "< %EVR" ("= %EVR" makes little sense;
"> %EVR" looks strange because it's about obsoleting packages from future).
The rpm program can be "new" (which knows how to compare E:V-R:Ds with
disttags; since 4.13.0.1-alt5) or "old" (does not yet know it;
4.13.0.1-alt4 or earlier).
(rpm-build already produces "new" packages, i.e., with disttags.)
The "new" rpm program is considered to be the correct reference way to
treat disttags. According to it, the presence of a disttag in a < or >
dependency cannot affect its interpretation (whether it is satisfied
by another package). Adding a disttag to a = dependency would simply
make it more strict (and that's what rpm-build already does under the
hood for intersubpackage deps). So, E:V-R:D deps are OK for the "new"
rpm.
So, what about about the "old" rpm?
Let's pay attention to the cases where the "old" rpm behaves
differently from the "new" rpm.
Such differences can be demonstrated by running
rpminstall-tests-1.0-alt2.M70P.1 in a system with an "old" rpm and a
"new" rpm-build (that can produce packages with disttags).
Here are the interesting failed test cases without disttag in the dependencies
(like before the change made by this commit), i.e. with dependencies
in the form E:V-R written in Conflicts or Obsoletes:
* installable_dummyDisttag_with_conflGreaterEpoch (and similar ones)
$ rpm -qp RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm --provides
dummy = 1-alt1:zzz+777.66
$ rpm -qp RPMS/conflGreaterEpoch/noarch/conflGreaterEpoch-1-alt1.noarch.rpm --conflicts
dummy > 0:1-alt1
$ rpm -i RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm RPMS/conflGreaterEpoch/noarch/conflGreaterEpoch-1-alt1.noarch.rpm
error: Failed dependencies:
dummy > 0:1-alt1 conflicts with conflGreaterEpoch-1-alt1.noarch
NOT OK (ALT#35930): this form of Conflicts is used to ensure that no
subpackages from different releases/builds get installed together.
* noninstallable_dummyDisttag_with_conflEqualEpoch (and similar ones)
$ rpm -qp RPMS/conflEqualEpoch/noarch/conflEqualEpoch-1-alt1.noarch.rpm --conflicts
dummy = 0:1-alt1
$ rpm -i RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm RPMS/conflEqualEpoch/noarch/conflEqualEpoch-1-alt1.noarch.rpm
succeeds
NOT OK: this form of conflicts could be used to declare conflicting subpackages.
Here are the interesting failed test cases with disttag in the
dependencies (like after the change made by this commit), i.e. with
dependencies in the form E:V-R:D written in Conflicts or Obsoletes:
* installable_dummy_with_conflLessEpochDisttag (and similar ones),
$ rpm -qp RPMS/dummy/noarch/dummy-1-alt1.noarch.rpm --provides
dummy = 1-alt1
$ rpm -qp RPMS/conflLessEpochDisttag/noarch/conflLessEpochDisttag-1-alt1.noarch.rpm --conflicts
dummy < 0:1-alt1:zzz+777.66
$ rpm -i RPMS/dummy/noarch/dummy-1-alt1.noarch.rpm RPMS/conflLessEpochDisttag/noarch/conflLessEpochDisttag-1-alt1.noarch.rpm
error: Failed dependencies:
dummy < 0:1-alt1:zzz+777.66 conflicts with conflLessEpochDisttag-1-alt1.noarch
OK: dummy-1-alt1.noarch.rpm is from another build (if built with the
"new" rpm-build, it would include the disttag in Provides). This form
of Conflicts is used to ensure that no subpackages from different
releases/builds get installed together. The difference in behavior
with the "new" rpm is explained by that the "new" rpm cannot
(unfortunately) detect this subtle mismatch.
* nonobsoleted_dummy_with_obsolLessEpochDisttag (and similar ones)
(like the previous case)
$ rpm -qp RPMS/obsolLessEpochDisttag/noarch/obsolLessEpochDisttag-1-alt1.noarch.rpm --obsoletes
dummy < 0:1-alt1:zzz+777.66
$ rpm -i RPMS/dummy/noarch/dummy-1-alt1.noarch.rpm RPMS/obsolLessEpochDisttag/noarch/obsolLessEpochDisttag-1-alt1.noarch.rpm
$ rpm -q dummy
package dummy is not installed
OK
* nonobsoleted_dummyDisttag_with_obsolLessEpochDisttag (and similar ones)
$ rpm -qp RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm --provides
dummy = 1-alt1:zzz+777.66
$ rpm -qp RPMS/obsolLessEpochDisttag/noarch/obsolLessEpochDisttag-1-alt1.noarch.rpm --obsoletes
dummy < 0:1-alt1:zzz+777.66
$ rpm -i RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm RPMS/obsolLessEpochDisttag/noarch/obsolLessEpochDisttag-1-alt1.noarch.rpm
$ rpm -q dummy
package dummy is not installed
NOT OK, but very improbable (the real name of the subpackage must be
the same as the obsoleted name of an older package, but the obsoleting
package is a different subpackage; so, it's improbable that one keeps
the old name of a subpackage, but wants to obsolete it with another
subpackage).
So, introducing this change to the %EVR value would make the new
packages be treated better by the "old" rpm; even the treatment in the
cases where the behavior is different from the behavior of the "new"
rpm is good (except for one improbable case).
getopt(3) holds pointers to previous argument vector in case you want to
continue or restart parsing.
In grabArgs function argument vector is on the stack, so you are lucky
if this memory is not reused for something else between subsequent calls
to the function. If you are not lucky, getopt(3) will read new
arbitrary value from the stack and return error.
The patterns used were OK for the output of "file -NF$'\t'": it would
put a space after the separator (the default separator being ":").
But not for the output of "file -b": we need to pad the result with a
space to use the same patterns.
Putting a space at the beggining is convenient, because it allows to
match independently for "* sh" or "* bash", otherwise "*sh" would
consume "bash", too.
Other uses of "file -b" in scripts/ don't suffer from this problem.
- spec: replaced deprecated PreReq tags with Requires tags.
- Added automatic conversion of deprecated PreReq tags to Requires tags.
- Disallowed extra qualifiers with BuildPreReq tag.
- Disallowed unknown qualifiers with Requires and BuildRequires tags.
- Allowed abbreviated qualifiers with Requires and BuildRequires tags.
- Moved ProvidedSymbols() and SuggestBPP() to separate files.
- lib.prov: Added printing of the number of provided symbols
and the bpp value for each library.
- lib.req: Updated the list of standard libraries with guaranteed versioning.
- suggest_bpp: Fixed harmless off-by-one error in bpp estimation.
ProvidedSymbols() used to be defined both in lib.prov.in and lib.req.in,
fix this code duplication by moving ProvidedSymbols() to separate
provided_symbols executable script.
Likewise, SuggestBPP() used to be defined both in lib.prov.in and
lib.req.in, fix this code duplication by moving SuggestBPP() to separate
suggest_bpp executable script.
Convert PreReq tags without qualifiers into Requires(pre,postun)
and PreReq tags with qualifiers into Requires tags with those qualifiers.
This matches compare_deps() behaviour and opens the way
for additional optimizations of dependencies.
Before this change unknown qualifiers were silently ignored if they
happened to be the last or the only qualifier, e.g. Requires(trash) or
Requires(pre,trash) were accepted but Requires(trash,post) were not.
Now all unknown qualifiers are treated as errors.
Before this change abbreviated qualifiers like BuildRequires(pre)
were silently ignored as unknown, now unambiguously abbreviated qualifiers
are handled like non-abbreviated.
Forgot how nasty hack parseBits() was... its abusing multilang
support and the multilang support passes "C" if no lang is specified,
which certainly isn't a valid qualifier. Make multilang vs tag with
optional qualifiers different types in PreambleRec, which allows
handling this more sanely.
(cherry picked from commit dbec3664232852425d9e966058cb02e6c5f6689c)
PreReqs differ from regular requirements, they need special treatment.
Also do not add RPMSENSE_FIND_REQUIRES unnecessarily.
Fixes: 4.0.4-alt122~2 ("addReqProv: implement dep flags merge")
lld linked binaries differ by structure from GNU ld, so eu-lint will
always complaint about. Allow to skip those checks by passing
%set_verify_elf_method lint=(skip|no)
Signed-off-by: Konstantin A. Lepikhov <lakostis@altlinux.ru>
- Dropped $RPM_STRICT_INTERDEPS support
(introduced in 4.0.4-alt110).
- Made name, version, release, and disttag check stricter
(by vseleznv@ and me).
- Changed the generator of package self-provides
and the generator of strict intersubpackage dependencies
to use [E:]V-R[:D] format instead of [E:]V-R
(by vseleznv@ and me).
- addReqProv: implemented dep flags merge:
when a stronger requirement is added while a weaker one already exists
with incompatible flags, try to merge these flags to produce a new
stronger requirement. For example,
"PreReq: %name = %version" + "Requires: %name = %version-%release"
now results to "PreReq: %name = %version-%release".
When a stronger requirement is added while a weaker one already exists
with incompatible flags, try to merge these flags to produce a new
stronger requirement.
For example,
"PreReq: %name = %version" + "Requires: %name = %version-%release"
now results to "PreReq: %name = %version-%release", and
"PreReq: %name = %EVR" + "Requires: %name = %EVRD"
now results to "PreReq: %name = %EVRD".
Backport rpmCharCheck() from rpm-4.13.0.1-release, replace rasprintf()
and risalnum() with asprintf() and isalnum() respectively, check
VERSION and RELEASE tags against whitelisted characters. The whitelist
only contains all alphanumeric symbols as well as "._+" symbols.
[ldv:
Rewritten, all code from rpm is terrible.
Extended to NAME and DISTTAG.]
This enhances ProvidedSymbols() in two ways:
* fixes st_shndx check for the case when it is not $7 in
"readelf --wide --dyn-syms" output as it happens on some architectures
like ppc64le;
* filters out special symbols (__bss_start, _edata, _end, _fini, _init)
after stripping of versioning.
Co-Authored-by: Dmitry V. Levin <ldv@altlinux.org>
- Add _allow_deps_with_beginning_dot macro to allow dependencies
beginning with a dot character (such as ones generated by replaceDeps
function) in spec file (vseleznv@).
After commit f4d876f93 rpm-build may generate dependencies beginning
with a dot character, but spec parser refuses such dependencies.
rpmrebuild fails to rebuild packages with such dependencies because it
builds packages with rpmbuild from generated spec files.
