On Apr 5, 2011, at 5:19 PM, Per Øyvind Karlsen wrote:

> 2011/4/5 Jeff Johnson <n3...@mac.com>:
>> 
>> On Apr 5, 2011, at 4:13 PM, Per Øyvind Karlsen wrote:
>> 
>>>> 
>>> Hm, okay, so better obviously needs to be done.
>>> 
>> 
>> Have a go at fixing if you wish.
> Here's the code that breaks things:
>    /* Lose the inheirited %description (if present). */
>    {  HE_t he = memset(alloca(sizeof(*he)), 0, sizeof(*he));
>       int xx;
>       he->tag = RPMTAG_DESCRIPTION;
>       xx = headerGet(pkg->header, he, 0);
>       he->p.ptr = _free(he->p.ptr);
>       if (xx && he->t == RPM_STRING_TYPE)
>           xx = headerDel(pkg->header, he, 0);
>    }
> 

And here's the utterly trivial 1 line fix that permits Mandriva
to continue using
        %description -l XY
syntax that was abandoned in RHL (not RHEL) 6.2 like 10 years ago:

Index: build/parseDescription.c
===================================================================
RCS file: /v/rpm/cvs/rpm/build/parseDescription.c,v
retrieving revision 2.44
diff -p -u -w -r2.44 parseDescription.c
--- build/parseDescription.c    16 Feb 2010 15:12:21 -0000      2.44
+++ build/parseDescription.c    6 Apr 2011 01:33:26 -0000
@@ -90,6 +90,7 @@ int parseDescription(Spec spec)
     }
 
     /* Lose the inheirited %description (if present). */
+    if (spec->packages->header != pkg->header)
     {  HE_t he = memset(alloca(sizeof(*he)), 0, sizeof(*he));
        int xx;
        he->tag = RPMTAG_DESCRIPTION;

Please note that the "fix" limits
        %description -l XY
usage to main package only, not sub-pkgs. I see the inheiritance into subpkgs,
thereby making %description "optional", as the more important feature
here than maintaining compatibility with an implementation that was
abandoned almost 10 years ago because RPM_I18NSTRING_TYPE is design flawed.

Here is the "proof" that the 1-line patch fixes the reproducer (I most 
definitely appreciate reproducers)
you gave me:

        $ rpm -qp --yaml lang-test-1-1.pentium4.rpm 
        - !!omap
          Headeri18ntable:
            - C
            - nb_NO.UTF-8
            - de.UTF-8
            - da.UTF-8
        ...
          Description:     - ~
            - nb_NO
            - de
            - da

I decline to fix RPM_I18NSTRING_TYPE issues in rpm > 5.4.0
for many reasons, including:

        1) Mandriva (and PLD) are the only two distro usage cases remaining on 
the planet afaik.
        Both distros have had almost a decade to convert to something else. 
Enough already ...

        2) I personally (and quite strongly) believe that RPM_I18NSTRING_TYPE is
        design flawed and useless in RPM, and I no longer wish to be called to 
task to "fix"
        compatibility with ancient "legacy compatibility" hysteria on time 
critical distro
        delivery paths. 

(aside)
Not that devising a 1-line patch was very hard. Took only 2 bottles of sake and
a plate of sashimi to figger. That's isn't a hard hack, five bottles of sake is 
hard ;-)

Basically -- at some point -- there's nothing left to do but haul out the trash 
code
in rpmbuild (from 1998) imho.

And so I will do that instead. I plan to rip out
        %description -l XY
syntax (basically by parsing and ignoring the syntax, like %clean and 
BuildRoot:) in rpm-5.4.1
going forward.

Less than 10% of Cooker packages (892 of 12337) are still using
        %description -l XY
syntax in spec files. That is a hard task iff there is time pressure, like post 
beta,
pre-release. A imple awk script run across Mandriva svn will eliminate the 
sections
in *.spec files.

You can do what you wish with the "fix" in rpm-5.3.x and with #ifdef 
RPM_VENDOR_MANDRIVA.

I've personally had enuf of RPM_I18NSTRING_TYPE functionality (sic) for a 
lifetime already, and
no longer wish to support RPM "features" which I don't believe in simply out
of my own personal ethic, and sense of duty and obligation.

73 de Jeff______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org

Reply via email to