Re: [gentoo-portage-dev] handling config stuff in portage (for package compression, etc)

2005-11-07 Thread Jason Pepas 
On Mon, Nov 07, 2005 at 12:11:55AM +0100, Marius Mauch wrote:
  For example, if Z=bzip2, a file would be sourced (bzip2.sh), which
  would contain the these settings:
  
  ZEXT=bz2
  TZEXT=tbz2
  ZCOMPRESS=bzip2
  ZDECOMPRESS=bunzip2
  ZFILTER=bzip2
  ZUNFILTER=bunzip2
  ZRECOMPRESS=no
 
 Why this indirection? Just for convienience or are there technical
 reasons? If it's just convienience then you don't need this, just
 utilize the source command in make.conf. Anyway, there is no place for
 one-letter vars in make.*

I see no way of avoiding making things hard coded without making a
sepparate file for each compression method.

  The following subsystems would source one of these files to get
  their settings:
  
  PKG_
  DOC_
  MAN_
  INFO_
  
  possibly others.
  
  So, if PKG_Z=bzip2, bzip2.sh would be read to set PKG_ZEXT,
  PKG_TZEXT, PKG_ZCOMPRESS, etc.
 
 Why are those vars needed? Can't they be directly derived from the
 global ones?

Without these vars, how would you use bzip2 for packages but use gzip
for man pages (as the current gentoo does)?  The global ones would all
be specific to one method of compression...

  As these module files are sourced, individual config options could be
  overridden via values in the environment.  For example, if I wanted
  gzip used across the board, but I wanted different levels of
  compression for man pages and packages, I could do this in make.conf:
  
  Z=gzip
  PKG_ZCOMPRESS=gzip --best
  MAN_ZCOMPRESS=gzip --fast
 
 Somehow this part looks like overengineering to me. Doesn't seem worth
 to introduce 7*4=28 new vars just for this.

Yeah, this is the problem I am stuck at: adding 28 new vars is
ridiculous, but I am having trouble seeing another way of doing this, so
I asked the mailing list.

I thought about it some more and perhaps a better way of doing this
would be to only specify the method of compression for each subsystem
using env vars.  So, you would only have:

PORTAGE_COMPRESS_PKG
PORTAGE_COMPRESS_MAN
PORTAGE_COMPRESS_DOC
PORTAGE_COMPRESS_INFO

Then, something internal to portage would take the value of that var and
lookup the rest of what was needed somewhere else.

-jason pepas
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] handling config stuff in portage (for package compression, etc)

2005-11-06 Thread Marius Mauch 
On Sat, 5 Nov 2005 20:58:57 -0600
Jason Pepas [EMAIL PROTECTED] wrote:

 So, I have been going over how class config works in portage, but I
 am still unsure of where to fit in the changes I would need.
 
 I suppose I'll lay out the structure of what I had in mind and ask
 y'all for advice.
 
 Compression would be supported in a modular fashion.  The following
 config options would be supported for each type of compression:
 
 ZEXT - the compression filename extension
 TZEXT - the binary package filename extension
 ZCOMPRESS - the command used to compress a file
 ZDECOMPRESS - the command used to uncompress a file
 ZFILTER - command used to compress in a pipeline
 ZUNFILTER - command used to uncompress in a pipeline
 ZRECOMPRESS - should files already compressed using another method be
 uncompressed and then recompressed using the preferred method? (ie, if
 manpages are shipped as foo.1.gz and you want foo.1.bz2)

I really don't like this Z prefix, should rather be
PORTAGE_COMPRESS_{EXT,BINEXT,COMPRESSCOMMAND,...}
(avoid env namespace pollution a IMO a lot cleaner)

 For example, if Z=bzip2, a file would be sourced (bzip2.sh), which
 would contain the these settings:
 
 ZEXT=bz2
 TZEXT=tbz2
 ZCOMPRESS=bzip2
 ZDECOMPRESS=bunzip2
 ZFILTER=bzip2
 ZUNFILTER=bunzip2
 ZRECOMPRESS=no

Why this indirection? Just for convienience or are there technical
reasons? If it's just convienience then you don't need this, just
utilize the source command in make.conf. Anyway, there is no place for
one-letter vars in make.*

 The following subsystems would source one of these files to get
 their settings:
 
 PKG_
 DOC_
 MAN_
 INFO_
 
 possibly others.
 
 So, if PKG_Z=bzip2, bzip2.sh would be read to set PKG_ZEXT,
 PKG_TZEXT, PKG_ZCOMPRESS, etc.

Why are those vars needed? Can't they be directly derived from the
global ones?

 As these module files are sourced, individual config options could be
 overridden via values in the environment.  For example, if I wanted
 gzip used across the board, but I wanted different levels of
 compression for man pages and packages, I could do this in make.conf:
 
 Z=gzip
 PKG_ZCOMPRESS=gzip --best
 MAN_ZCOMPRESS=gzip --fast

Somehow this part looks like overengineering to me. Doesn't seem worth
to introduce 7*4=28 new vars just for this.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpw5V5iOCAyQ.pgp
Description: PGP signature