[Rpm-maint] [rpm-software-management/rpm] parseBits: disallow syntax errors and unknown qualifiers (#623)

[Dmitry V. Levin]

The previous attempt to fail build in case of syntax errors
and unknown dependency qualifiers made in commit
rpm-4.8.0-beta1-385-gbf2bc18ebb325f081ade65adc2fbb6858f0b8396
missed the following classes of erroneous dependencies:

Requires(,) -- erroneously treated as Requires(),
Requires(;) -- erroneously treated as Requires(),
Requires(,pre) -- erroneously treated as Requires(),
Requires(;pre) -- erroneously treated as Requires(),
Requires(pre,) -- erroneously treated as Requires(pre),
Requires(pre,,postun) -- erroneously treated as Requires(pre),
Requires(pre,,junk) -- erroneously treated as Requires(pre),
Requires(pre;postun) -- erroneously treated as Requires(pre),
Requires(pre;junk) -- erroneously treated as Requires(pre).

Found by code inspection.

Fixes: bf2bc18ebb32 ("Always fail build on unknown dependency qualifiers")
You can view, comment on, or merge this pull request online at:

  https://github.com/rpm-software-management/rpm/pull/623

-- Commit Summary --

  * tests: check rpmspec --query handling of requirements
  * parseBits: disallow syntax errors and unknown qualifiers

-- File Changes --

M build/parsePreamble.c (14)
M tests/Makefile.am (2)
A tests/data/SPECS/test-parsebits.spec (27)
A tests/rpmspec.at (230)
M tests/rpmtests.at (1)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/623.patch
https://github.com/rpm-software-management/rpm/pull/623.diff

-- 
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/623
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] doc/manual/dependencies: remove reference to %__find_prereq (#621)

[Dmitry V. Levin]

This is the last reference to %__find_prereq macro,
the support for this macro was removed long time ago
by commit 44e5913dae80f1040748441af35fb02b840c397a.
You can view, comment on, or merge this pull request online at:

  https://github.com/rpm-software-management/rpm/pull/621

-- Commit Summary --

  * doc/manual/dependencies: remove reference to %__find_prereq

-- File Changes --

M doc/manual/dependencies (2)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/621.patch
https://github.com/rpm-software-management/rpm/pull/621.diff

-- 
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/621
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Add %optional tag (#417)

[Dmitry V. Levin]

%optional essentially means "please include this file into the package, but I'm 
explicitly OK if it disappears from the package at any time for whatever reason 
because I don't care".
Specfile syntax in its current form is already used for careless packaging, 
there is hardly any need to encourage bad practices by introducing new features 
like %optional.

-- 
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/417#issuecomment-376226997___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Use C.UTF-8 locale, if available (#227)

[Dmitry V. Levin]

wrt glibc community, please have a look at 
https://sourceware.org/glibc/wiki/Proposals/C.UTF-8

-- 
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/227#issuecomment-339720098___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Revert "Revert "Only build bundled fts if system has a bad version th… (#324)

[Dmitry V. Levin]

@pmatilai, you are a perfect marvel! Thank you for being so grateful to us for 
getting rid of bundled X and fixing your buggy Z.
Thanks everybody for this enlightening discussion, I suppose no more comments 
are needed here.

-- 
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/324#issuecomment-329160467___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Revert "Revert "Only build bundled fts if system has a bad version th… (#324)

[Dmitry V. Levin]

@n3npq Why should rpm ever want to walk a remote URI?

Anyway, rpm.org doesn't need its copy of fts.c when linked with glibc >= 2.23, 
and the bug is that
- rpm.org's maintainer is not ready to admit this fact and act accordingly;
- his attitude to contributors discourages further contributions.

-- 
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/324#issuecomment-328811762___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Revert "Revert "Only build bundled fts if system has a bad version th… (#324)

[Dmitry V. Levin]

@n3npq I wish to get rid of fts.c completely, as well as all other stuff that 
belongs to glibc.
I wish you haven't added that stuff in the first place! :)

-- 
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/324#issuecomment-328806244___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Revert "Revert "Only build bundled fts if system has a bad version th… (#324)

[Dmitry V. Levin]

@pmatilai, how often do you sync your copy of fts.c with glibc?
I bet your fts.c doesn't have any fixes made in glibc since the last sync.

-- 
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/324#issuecomment-328692165___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] Revert "Only build bundled fts if system has a bad version that doesn't handle LFS"

[Dmitry V. Levin]

On Fri, Aug 18, 2017 at 08:22:23AM +0300, Panu Matilainen wrote:
> On 08/17/2017 11:28 PM, Dmitry V. Levin wrote:
> > On Thu, Aug 17, 2017 at 08:16:12AM +0300, Panu Matilainen wrote:
> >> On 08/16/2017 11:51 PM, Dmitry V. Levin wrote:
> >>> On Thu, Aug 10, 2017 at 08:15:02PM +0300, Panu Matilainen wrote:
> >>>> The subtle test is too subtle for its own good, this patch breaks
> >>>> thirty six testcases on 32bit architectures.
> >>>>
> >>>> This reverts commit 1eadabe4453ef32eb6c3bc837094e1ca998affcc.
> > [leaving non-technical part aside for a while]
> >> But as the
> >> revert commit message says, the test is way too subtle for my liking, I
> >> never liked it at all because of that. In retrospective, that distrust
> >> combined with the clock-is-ticking situation ... I don't think I  ever
> >> actually thought to suspect fakechroot in this case.
> > 
> > Sorry but your distrust of AC_CHECK_HEADERS([fts.h]) looks rather 
> > irrational.
> > What kind of doubts do you have wrt this very basic test?
> > 
> > Do you have any doubts about AC_CHECK_HEADERS documented behaviour, e.g.
> > that it uses the compiler to test header usability, and it is affected
> > by the arrangements made by AC_SYS_LARGEFILE?
> > 
> > Even the memorable 8-year-old change of AC_CHECK_HEADERS behaviour
> > described in [1] shouldn't affect this case because glibc's fts.h used
> > to issue an "#error" in case of _FILE_OFFSET_BITS==64 thus breaking
> > the preprocessor test, too.
> > 
> > There are plenty of AC_CHECK_HEADERS invocations in configure.ac -
> > do they also look doubtful to you?
> 
> Meh.
> 
> "Any technology, no matter how primitive, is magic to those who don't 
> understand it."
> 
> The "earlier configure.ac foo hidden side-effects cause this to do 
> something else" that somehow ends up being completely counter-intuitive 
> and magic to me.

You hardly can call them hidden because they are clearly documented,
e.g. 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/html_node/System-Services.html#index-AC_005fSYS_005fLARGEFILE-1102
says "Define _FILE_OFFSET_BITS and _LARGE_FILES if necessary".

> I'm still deep in the superstition phase when in comes to autoconf ;)

You know, this can be fixed, too. ;)


-- 
ldv


signature.asc
Description: PGP signature
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] Revert "Only build bundled fts if system has a bad version that doesn't handle LFS"

[Dmitry V. Levin]

On Thu, Aug 17, 2017 at 08:16:12AM +0300, Panu Matilainen wrote:
> On 08/16/2017 11:51 PM, Dmitry V. Levin wrote:
> > On Thu, Aug 10, 2017 at 08:15:02PM +0300, Panu Matilainen wrote:
> >> The subtle test is too subtle for its own good, this patch breaks
> >> thirty six testcases on 32bit architectures.
> >>
> >> This reverts commit 1eadabe4453ef32eb6c3bc837094e1ca998affcc.
[leaving non-technical part aside for a while]
> But as the 
> revert commit message says, the test is way too subtle for my liking, I 
> never liked it at all because of that. In retrospective, that distrust 
> combined with the clock-is-ticking situation ... I don't think I  ever 
> actually thought to suspect fakechroot in this case.

Sorry but your distrust of AC_CHECK_HEADERS([fts.h]) looks rather irrational.
What kind of doubts do you have wrt this very basic test?

Do you have any doubts about AC_CHECK_HEADERS documented behaviour, e.g.
that it uses the compiler to test header usability, and it is affected
by the arrangements made by AC_SYS_LARGEFILE?

Even the memorable 8-year-old change of AC_CHECK_HEADERS behaviour
described in [1] shouldn't affect this case because glibc's fts.h used
to issue an "#error" in case of _FILE_OFFSET_BITS==64 thus breaking
the preprocessor test, too.

There are plenty of AC_CHECK_HEADERS invocations in configure.ac -
do they also look doubtful to you?

[1] 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/html_node/Present-But-Cannot-Be-Compiled.html


-- 
ldv


signature.asc
Description: PGP signature
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] Add rpmbuild debuginfo subpackages tests.

[Dmitry V. Levin]

On Fri, Jul 28, 2017 at 09:55:24PM +0200, Mark Wielaard wrote:
> This adds various tests for making sure multiple subpackages are build
> correctly. Without debuginfo subpackages, with subpackages, subpackages
> with unique debug file and source dir paths and with separate debugsources.
[...]
> +# Check that there are is just one debuginfo packages.

I'm not really reviewing this, but when reading this comment,
I'm not quite sure how many packages are expected. ;)


-- 
ldv


signature.asc
Description: PGP signature
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] config: Detect major/minor warnings and include the correct system header.

[Dmitry V. Levin]

On Wed, Jul 19, 2017 at 02:49:38PM +0200, Mark Wielaard wrote:
> glibc 2.25 introduced (really long and annoying) warnings for each use
> of the major/minor macros from the wrong header:
> 
> lib/cpio.c: In function ‘rpmcpioHeaderWrite’:
> lib/cpio.c:245:13: warning: In the GNU C Library, "major" is defined
>  by . For historical compatibility, it is
>  currently defined by  as well, but we plan to
>  remove this soon. To use "major", include 
>  directly. If you did not intend to use a system-defined macro
>  "major", you should undefine it after including .
>  dev = major(st->st_dev); SET_NUM_FIELD(hdr->devMajor, dev, field);
>  ^~
> 
> Adjust the configure check and undef the warning producing macros to get
> rid of the wrong definitions and use the macros from the right include.
> 
> Tested against RHEL7 (glibc 2.17) and Fedora 26 (glibc 2.25).
> 
> Signed-off-by: Mark Wielaard 
> ---
>  configure.ac | 8 
>  lib/cpio.c   | 6 ++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/configure.ac b/configure.ac
> index cc657ec..017a908 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -561,7 +561,15 @@ AM_ICONV
>  
>  dnl Checks for header files we can live without.
>  AC_HEADER_STDC
> +dnl glibc and autoconf don't really play well together.
> +dnl glibc will produce a warning when including the wrong header.
> +dnl but still define major and minor. Causing us to include the header
> +dnl that produces a giant warning for each major/minor use.
> +dnl Use -Werror to work around that.
> +old_CFLAGS=$CFLAGS
> +CFLAGS="$CFLAGS -Werror"
>  AC_HEADER_MAJOR
> +CFLAGS=$old_CFLAGS
>  AC_STRUCT_DIRENT_D_TYPE
>  
>  AC_CHECK_HEADERS(limits.h)
> diff --git a/lib/cpio.c b/lib/cpio.c
> index 57c9592..b7ba27d 100644
> --- a/lib/cpio.c
> +++ b/lib/cpio.c
> @@ -9,9 +9,15 @@
>  
>  #include "system.h"
>  
> +/* system.h might already have included the wrong header, undef major
> +   and minor and get the real definition from one of the correct headers. */
>  #if MAJOR_IN_MKDEV
> +#undef major
> +#undef minor
>  #include 
>  #elif MAJOR_IN_SYSMACROS
> +#undef major
> +#undef minor
>  #include 
>  #else
>  #include  /* already included from system.h */

I'm not sure what sys/mkdev.h does, but glibc's sys/sysmacros.h certainly
undefines major, minor, and makedev prior to defining its own versions of
these macros.

My guess is that these undefs are not needed.


-- 
ldv


signature.asc
Description: PGP signature
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Incorrect __progname definition (#203)

[Dmitry V. Levin]

No, fa06b68 is fine; musl provides __progname, all Yocto needs is just use it.

-- 
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/203#issuecomment-297351148___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] Support debugsource subpackages

[Dmitry V. Levin]

On Fri, Mar 24, 2017 at 04:15:36PM +0100, Michael Schroeder wrote:
> 
> The attached patch makes rpm create -debugsource subpackages containing
> the debug sources.
[...]
> +if [ -n "$srcout" ]; then
> +  > "$srcout"
> +  if [ -d "${RPM_BUILD_ROOT}/usr/src" ]; then
> +(cd "${RPM_BUILD_ROOT}/usr"
> + test ! -d src/debug || find src/debug -mindepth 1 -maxdepth 1
> +) | sed 's,^,/usr/,' >> "$srcout"
> +  fi
> +fi
> +

Why do you need two subsequent checks here?  This could be done with
a single [ -d "${RPM_BUILD_ROOT}/usr/src/debug" ] check.


-- 
ldv


signature.asc
Description: PGP signature
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH 3/5] Drop local implementation of xsetprogname/xgetprogname

[Dmitry V. Levin]

On Thu, Mar 23, 2017 at 03:08:57PM -0400, Neal Gompa wrote:
> On Thu, Mar 23, 2017 at 2:22 PM, Gleb Fotengauer-Malinovskiy wrote:
> > It can be dropped because this code was never actually enabled.
> > Actually, this implementation *surely* never ever compiled.
> 
> Are you sure of this? Because this is supposed to be wired up so RPM
> builds and runs correctly on BSDs and Mac OS X... If it's not, then
> that's a problem...

Just have a look at the code, it's pretty obvious that it's never been
compiled.


-- 
ldv


signature.asc
Description: PGP signature
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] parseSpec: use getline instead of fgetc

[Dmitry V. Levin]

On Mon, Mar 13, 2017 at 07:17:40PM +0300, Gleb Fotengauer-Malinovskiy wrote:
> Replace home-grown buggy imitation of getline(3) with use of getline(3).
> 
> Fixes: 92a8babf1b46 ("Remove hopefully the last static buffer in rpm spec 
> reading")
> Closes: https://github.com/rpm-software-management/rpm/issues/175
> Signed-off-by: Gleb Fotengauer-Malinovskiy <gle...@altlinux.org>

Reviewed-by: Dmitry V. Levin <l...@altlinux.org>

fwiw, we've been using this getline approach in parseSpec
for almost 5 years
(http://git.altlinux.org/gears/r/..git?p=rpm-build.git;a=commitdiff;h=4.0.4-alt100.47-4-g12538e4)
so it has received a very extensive testing.

> ---
>  build/parseSpec.c | 19 ++-
>  1 file changed, 2 insertions(+), 17 deletions(-)
> 
> diff --git a/build/parseSpec.c b/build/parseSpec.c
> index 20c4555..2928e85 100644
> --- a/build/parseSpec.c
> +++ b/build/parseSpec.c
> @@ -32,7 +32,7 @@ typedef struct OpenFileInfo {
>  FILE *fp;
>  int lineNum;
>  char *readBuf;
> -int readBufLen;
> +size_t readBufLen;
>  const char * readPtr;
>  struct OpenFileInfo * next;
>  } OFI_t;
> @@ -323,22 +323,7 @@ retry:
>  
>  /* Make sure we have something in the read buffer */
>  if (!(ofi->readPtr && *(ofi->readPtr))) {
> - int c;
> - int i = 0;
> -
> - while ((c = fgetc(ofi->fp)) != EOF) {
> - if (i >= ofi->readBufLen - 1) {
> - ofi->readBufLen += BUFSIZ;
> - ofi->readBuf = xrealloc(ofi->readBuf, ofi->readBufLen);
> - }
> - ofi->readBuf[i++] = c;
> - if (c == '\n') {
> - ofi->readBuf[i] = '\0';
> - break;
> - }
> - }
> -
> - if (!i) {
> + if (getline(>readBuf, >readBufLen, ofi->fp) <= 0) {
>   /* EOF, remove this file from the stack */
>   ofi = popOFI(spec);
>  

-- 
ldv


pgpzfOgnejjeE.pgp
Description: PGP signature
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] [WIP] Replace gzip/bzip2/xz with pigz/pbzip2/pxz for multicore (#126)

[Dmitry V. Levin]

ldv-alt requested changes on this pull request.

The idea is wrong: you cannot *replace* gzip, bzip2, and xz because they are 
much more widespread.  The implementation is wrong: it does not achieve the 
declared goal.



-- 
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/126#pullrequestreview-16543932___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] add brp helper scripts from mandriva's spec-helper (#122)

[Dmitry V. Levin]

ldv-alt requested changes on this pull request.



> @@ -0,0 +1,14 @@
+#!/bin/sh
+
+# If using normal root, avoid changing anything.
+if [ -z "$RPM_BUILD_ROOT" -o "$RPM_BUILD_ROOT" = "/" ]; then
+   exit 0
+fi
+
+find "$RPM_BUILD_ROOT" \( -type f -o -type l \) -name \*.la  -print0 |
+xargs  --no-run-if-empty -0 file -N -L |
+grep "libtool library file" |
+sed -e 's#: libtool library file.*##g' |

grep followed by sed? Really? Is it an accepted shell scripting style nowadays?

-- 
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/122#pullrequestreview-16280889___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] rpm2cpio and rpm2archive: don't write archive data to a terminal. (#116)

[Dmitry V. Levin]

First of all, the github review process is awful, a traditional post to the 
mailing list would be much better.

wrt your patch,

> fprintf(stderr, "%s: refusing to output archive data to a terminal.\n");
> fprintf(stderr, "%s: refusing to output cpio data to a terminal.\n");

what do you mean by not passing any argument to %s format specifier?

-- 
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/116#issuecomment-271085647___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] configure.ac: reference zlib when checking libmagic (#118)

[Dmitry V. Levin]

Are you going to submit patches like this to every project that uses -lmagic?
Are you going to list every library libmagic might happen to be linked with?

No, -lmagic users should not care about the list of libraries libmagic is 
linked with, sorry.

-- 
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/118#issuecomment-271054404___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] Planning for rpm 4.13.0 (-rc2)

[Dmitry V. Levin]

Hi,

On Fri, Oct 14, 2016 at 04:33:00PM +0300, Panu Matilainen wrote:
> 
> Hey folks,
> 
> Time to get rpm 4.13.0 out of the door. But in order to do that, we'll 
> need to cut -rc2 first, there's just too much change to jump right into 
> final.
> 
> The idea is to get -rc2 out next week (ie by Oct 21st at latest). If all 
> goes well we'll just rename that to -final in a few weeks time, if all 
> goes to hell we'll just have another -rc. Which I really, really dont 
> want to happen. So what I've planned for -rc2 is this rather 
> conservative cherry-picks from git master on top of the 4.13.x branch:
[...]
> Anyway, the list above is not set in stone, otherwise there'd be little 
> point in posting it here. If you think something absolutely critical is 
> missing from that list, or that something should not be there, now is 
> the time to speak up.

Please include rpmdb.c fixes (commits 4c6e51e2 and e5d3b9f6), they are
essential for apt-rpm.


-- 
ldv


pgpiPs3HR5ADh.pgp
Description: PGP signature
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] Check for undefined macros

[Dmitry V. Levin]

On Sun, Jan 27, 2013 at 05:27:09AM +, Alexey Tourbin wrote:
 This change introduces a generalized routine rpmExpandMacros() to expand
 macros on behalf of user input, with improved diagnostic facilities.
 In particular, one of its arguments is a callback function which is
 called whenever an undefined macro is encountered in user input.
 
 When specfile parser calls this routine, it supplies a custom function
 to handle undefined macros.  This function is keenly aware of specfile
 syntax: valid specfile tokens, such as %prep and %setup, when found in
 the right context, are not treated as undefined macros.  Otherwise,
 there are 3 possibilities.
 - Undefined macros in preamble and %pre/%post/... scriptlets raise
   an error, unless a non-build parse is performed; this is to prevent
   malformed packages from being built.
 - In other cases, a warning is issued.
 - Some tokens are permitted beyond their context (e.g. %ghost in
   %changelog), to comply with traditional/sloppy usage.  Also, undefined
   macros found in comments normally do not produce a warning.

The idea is certainly not new, it was implemented in ALT Linux in October
of 2005, actually.  This feature proved to be useful in catching subtle
specfile bugs caused by undefined macros.  Said that, one should
understand that a change that results to some previously acceptable
specfiles being rejected is a policy enforcement.  Whether it is a good
idea to impose this specfile check without some grace period during which
newly recognized specfile errors are reported but not yet raise errors
depends on your user base, percentage of specfiles affected by the change,
how long it would take to fix them all, etc.  In ALT Linux, we chosen no
grace period option and introduced %_allow_undefined_macros macro
allowing users to relax the check.  Of course, your mileage may vary.

Finally, I'd like to thank Alexey for bringing this feature to a wider
audience.


-- 
ldv


pgpeYIis_84RO.pgp
Description: PGP signature
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint