Re: [gentoo-dev] bzipped manpages
On Jan 11 13:34:09, sven.e...@gmx.de wrote: > Am Dienstag, 10. Januar 2017, 13:36:15 CET schrieb Jan Stary: > > > You arguing that 40MB is nothing on modern systems (which, by the way is > > > not exactly true, talking about embedded ones). > > > > Can you gove an example of an embedded system with manpages? > > My Raspberry Pi 3. ;-) How is that an embedded system? It's a full blown linux installation.
Re: [gentoo-dev] bzipped manpages
On 01/10/2017 06:54 AM, Jan Stary wrote: > > These are workarounds. Let me get back to the original question: > would you please consider having _uncompressed_ manpages as the default? > > On this particular system, the bzipped /usr/share/man/ is 67M. > The uncompressed man/ is 108M. That's 40M saved. Seriously? Since everyone else is giving you a hard time, I think compressing all of the documentation by default is annoying and over-complicates things. However, if you asked me what *could* be compressed by default, man pages with their separate /usr/share/man directory and doman helper would be at the top of the list. They aren't meant to be read by humans, the default reader handles them, and they compress well. And in direct contradiction to my last paragraph, we did invent dohtml and now have PORTAGE_COMPRESS_EXCLUDE_SUFFIXES set to work around this exact problem, that web browsers won't call bunzip2 in a pipeline. It seems a little unfair to let web browsers off the hook but not mdocml. There are probably fewer people who care about the space than there are users who have been annoyed that they can't run an example because ruby/php/python won't run a compressed script. I know that we have "docompress", but inside the ebuild is the wrong place to battle an implementation-specific default setting.
Re: [gentoo-dev] bzipped manpages
Am Dienstag, 10. Januar 2017, 13:36:15 CET schrieb Jan Stary: > > You arguing that 40MB is nothing on modern systems (which, by the way is > > not exactly true, talking about embedded ones). > > Can you gove an example of an embedded system with manpages? My Raspberry Pi 3. ;-) Cheers Sven signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] package.use.mask / package.use.stable.mask priority
Le 11/01/2017 8:30, Ulrich Mueller a écrit :
On Tue, 10 Jan 2017, Zac Medico wrote:
On 01/10/2017 01:56 PM, Bernard Cafarelli wrote:
gnustep-base/gnustep-make has a USE flag (libobjc2) masked globally
in
base/package.use.mask, and unmasked on specific arches in
arch/{amd64,x86}/package.use.mask
To get a stabilization (#579232) bug finally moving on, I wanted to
leave this flag out, adding a corresponding line in
base/package.use.stable.mask
So do I understand this correctly, there is:
flag in base/package.use.mask,
-flag in arch/{amd64,x86}/package.use.mask, and
flag in base/package.use.stable.mask?
Exactly :)
But repoman replied with a batch of dependency.bad errors...
Does package.use.mask (stable and ~arch) have a higher priority on
package.use.stable.mask (stable only)? Bug or intended behavior?
If I understand you correctly, then it's the intended behavior. If the
flag is masked in both package.use.mask and package.use.stable.mask,
then the package.use.stable.mask setting is irrelevant because both
package.use.mask and package.use.stable.mask are considered when
calculating use.mask settings for any given package.
I believe this is not correct. package.use.stable.mask should take
precedence within the same profile:
https://projects.gentoo.org/pms/6/pms.html#x1-58002r1
The problem here is rather that the base profile is processed as a
whole before the arch specific profile, so you end up with -flag from
the arch profile.
Putting flag in arch/{amd64,x86}/package.use.stable.mask should solve
it.
Indeed, I tested (and committed) this yesterday and repoman was happy
again
--
Bernard Cafarelli (Voyageur)
Gentoo developer
Re: [gentoo-dev] package.use.mask / package.use.stable.mask priority
On 01/10/2017 11:30 PM, Ulrich Mueller wrote: >> On Tue, 10 Jan 2017, Zac Medico wrote: > >> On 01/10/2017 01:56 PM, Bernard Cafarelli wrote: >>> But repoman replied with a batch of dependency.bad errors... >>> Does package.use.mask (stable and ~arch) have a higher priority on >>> package.use.stable.mask (stable only)? Bug or intended behavior? > >> If I understand you correctly, then it's the intended behavior. If the >> flag is masked in both package.use.mask and package.use.stable.mask, >> then the package.use.stable.mask setting is irrelevant because both >> package.use.mask and package.use.stable.mask are considered when >> calculating use.mask settings for any given package. > > I believe this is not correct. package.use.stable.mask should take > precedence within the same profile: > https://projects.gentoo.org/pms/6/pms.html#x1-58002r1 Oh, right. I misunderstood because I misread the original email. I should have looked at the profile state to avoid a misunderstanding: profiles/arch/amd64/package.use.mask:gnustep-base/gnustep-make -libobjc2 profiles/arch/x86/package.use.mask:gnustep-base/gnustep-make -libobjc2 profiles/base/package.use.mask:>=gnustep-base/gnustep-make-2.6.2 libobjc2 I've checked the portage code and package.use.stable.mask does in fact take precedence within the same profile, because the UseManager getUseForce method uses an algorithm equivalent to the one specified in pms. -- Thanks, Zac
