On Apr 9, 2011, at 7:38 PM, Tomasz Pala wrote: > On Sat, Apr 09, 2011 at 19:05:33 -0400, Jeff Johnson wrote: > >> FOr a distro containing >1M files, empty string tags require (at least) '\0'. >> >> But ~1Mb (for a 1M file distro) additional info is moderately significant. >> Go look at >> ls -al /var/lib/rpm/Packages >> run >> rpm -qal | wc -l >> and then add that number of bytes for an empty tag. > > It's 0.3% in my case. >
SO add the tag. I can't justify the implementation for lots of reasons,
not only space. I answered what the overhead cost was, not what the
complexity cost is/was.
>> Then also add that to download times,
>
> You must be kidding - downloading 1 MB more considering entire distro is
> nothing.
>
I son't personally think download is worth worrying about.
Meanwhile -- for lots of reasons -- other do,
and blame RPM for "bloat".
>> and space on RO media.
>>
>> Already all strings are saved in rpmdb indices without trailing '\0'
>> in order to save several megabytes of space.
>
> Looking for a real savings?
>
> ~: grep install_langs /etc/rpm/*
> /etc/rpm/macros:%_install_langs pl_PL
> ~: LANG=pt_BR rpm -qi alsa-lib
> Bibliotecas para o ALSA. Esse pacote é necessário para rodar programas
> Linux queusam o driver de som ALSA.
>
> It would be sufficient to have some rpmdb postprocessing tools to remove
> descriptions or changelogs from database, especially for RO medias where
> no rollbacks would ever be required.
>
I'm well aware of the cost of RPM_I18NSTRING_TYPE. There are 2 distros
left using %description -l XY in *.spec recipes.
Mandriva is the other distro ... all @redhat derived distros stopped
using locales in *.spec a decade ago.
>>> There are patches - in rpm.org as you know.
>>
>> I'm well aware of what is @rpm.org even if you are not.
>
> Maybe I'm not - how does it even matter?
>
It doesn't matter -- we;re having a dscussion abt *.pyo files in python 3.2,
aren't we?
>> You claimed that rpm was preventing you from remoing SUID.
>
> Yeah - %caps() was added in 4.6 and we got 4.5 here in PLD.
>
You're foolish if you think 4.6 > 4.5 and hence "newer".
>> I'm also aware that Fedora tried removing SUID, and has packaged
>> with capabilities. *shrug*
>
> Are you aware that SUID (and superuser at all) could be disabled on
> destination host? Thus it's not required to actually remove this bit in
> package, The Point is to supply proper xattrs and leave user a choice.
>
SO remobve SUID's or disable SUID's or write the script that attaches
capabilities to 100-300 files (a generous over estimate considering
how few setuid programs ther actually are), and do whatever you please.
But it simply isn't true that RPM "package mangement" is stopping you
from implementing SUID removal or me from discussing chicks-in-charge.
A chick would be busily scrubbing out SUID's already ...
>> There's lots of ways to run a command against 100-300 files to
>> add capabilities "securely", without raciness, and without
>> getting "package management" involved.
>
> Assuming this "way" can undo transaction (full rollback) in context of
> privilidged process. How to setcap setcap binary after upgrade?
>
Re-run the script and write it with +capability/-capability and --rollback if
you ish.
>> SInce you are adding a capabity,
>> it just means that the file will be installed in unprivlieged
>> capabilty-free mode until the capability is added, just like SUID's.
>
> Unless one wokes up with no privilidged apps in system.
>
Too bad for you.
>> And ultimately, neither @rpm5.org or @rpm.org code is in use by PLD,
>> so it matters about as muct as radiation damage and chicks in charge
>> discussions.
>
> Eventually one of these will be used, but I doubt PLD is used in nuclear
> installations or by chicks in charge.
>
Wanna bet? AFAIK, PLD is happier with its own fork of RPM. I have offered
to assist with upgrade multiple times, gave up caring a few years back
because what PLD does is up to PLD.
But yes, there's a horrendous amount of "bloat" associated with
%description -l XY
WHich is why RPM_I18NSTRING_TYPE was abandoned (as in not used, yes the
implementation still exists, as b0rken as ever, in RPM) a decade ago.
But "Not yet." for PLD and Mandriva.
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
