public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] USE database?
@ 2001-12-03  1:06 Zach Forrest
  2001-12-03  7:41 ` AW: " Sebastian Werner
  2001-12-03 16:48 ` [gentoo-dev] USE database? Daniel Robbins
  0 siblings, 2 replies; 26+ messages in thread
From: Zach Forrest @ 2001-12-03  1:06 UTC (permalink / raw
  To: gentoo-dev

Hi. I've just signed up to the mailing list and wanted to put in my 2^n 
cents. I've just switched over from Debian and am very impressed with 
the Portage system and find administration and configuration to be very 
straight forward and enjoyable. I have learned a great deal about Linux 
in general during the transition (which is almost done -- I think). So, 
without further adieu....

One thing I think needs some refinement is the USE system. I was 
thinking that using a format that is more strict would allow for more 
flexibility and make it easier to automate both the process of 
generating the make.conf file and for tools to administer the USE 
variables. It may also allow for some improvements in the Portage system 
as well.

Using the docs in make.conf as the starting point, I think it would make 
sense to have a simple database format, or, if using python a list of 
dictionaries. For example, one entry might look like this:

use_var={"name":"esd",
          "description":"Enable enlightenment sound daemon support.",
          "priority":"OPTIONAL",
          "depends":"media-sound/esound"}

where:

priority => RECOMMENDED | REQUIRED | OPTIONAL | STANDARD |
             EXPERIMENTAL | DEPRECIATED | DONTUSE | CANNOTLIVEWITHOUT

depends  => packages required to satisfy the USE variable

Note the "depends" entry. This may allow the Portage system to become 
more flexible. Rather than just silently checking for use flags it may 
be nice to let the user know which USE variables are supported and 
possibly give the option to install supported packages, easily located 
through the "depends" field in the "database". This might serve as 
something similar to the Debian "recommended" package option. Maybe 
including a USE or OPTIONAL flag in the ebuild file that lists all of 
the possible USE options could be added.

Also, maybe adding a "--satisfyuse" flag to the ebuild/emerge command.

I know Gentoo is designed for more advanced users and what I have 
described may seem gratuitous, but I think it might make things easier 
in the long run. (Also, even advanced users can do with a _little_ 
convenience.)

It may, then, also make sense to give a little more structure to the 
optimization settings. For example:

optimization_var={
     "host":"i686",
     "chost":"i686-pc-linux-gnu",
     "cflags":"-mcpu=i686 -march=i686 -O3 -pipe",
     "cxxflags":"-mcpu=i686 -march=i686 -O3 -pipe"}

where:

host => i386 | i486 | i586 | i686 | k6 | athalon [ | ppc ]

And, for the sake of completeness, why not the FETCHCOMMAND:

fetch_cmd={
     "name":"Lukemftp",
     "command":"/usr/bin/lukemftp -s -a -o \${DISTDIR}/\${y} \${x}"}

If I recall correctly, my inspiration for all of this was when, during a 
recent update, I noticed that some new USE variables were available. I 
found it annoying to see which ones I had already included (searching 
through my long and possibly overkill USE string) and if there were any 
new ones that I wanted. Then I thought, "Gee, wouldn't a nice ncurses 
interface be great -- a couple of check boxes and then I have more time 
to attend to something only a little more important?"

As this is my first (and hopefully longest) message please give me some 
feedback, both good and bad -- I can take it.

I am thoroughly enjoying Gentoo Linux. Thank you to everyone.

Regards,
Zach Forrest



^ permalink raw reply	[flat|nested] 26+ messages in thread

* AW: [gentoo-dev] USE database?
  2001-12-03  1:06 [gentoo-dev] USE database? Zach Forrest
@ 2001-12-03  7:41 ` Sebastian Werner
  2001-12-03  9:13   ` Geert Bevin
  2001-12-03 11:32   ` [gentoo-dev] New ideas, USE database, sandbox & more Vitaly Kushneriuk
  2001-12-03 16:48 ` [gentoo-dev] USE database? Daniel Robbins
  1 sibling, 2 replies; 26+ messages in thread
From: Sebastian Werner @ 2001-12-03  7:41 UTC (permalink / raw
  To: gentoo-dev

Hey,

I like your idea. I have the same problems with the many variables I
could set. Some other idea I think could be good is to store the data
with gconf or something else (a binary registry - like windows but
better).

Sebastian Werner

-----Ursprüngliche Nachricht-----
Von: gentoo-dev-admin@gentoo.org [mailto:gentoo-dev-admin@gentoo.org] Im
Auftrag von Zach Forrest
Gesendet: Montag, 3. Dezember 2001 02:07
An: gentoo-dev@gentoo.org
Betreff: [gentoo-dev] USE database?

Hi. I've just signed up to the mailing list and wanted to put in my 2^n 
cents. I've just switched over from Debian and am very impressed with 
the Portage system and find administration and configuration to be very 
straight forward and enjoyable. I have learned a great deal about Linux 
in general during the transition (which is almost done -- I think). So, 
without further adieu....

One thing I think needs some refinement is the USE system. I was 
thinking that using a format that is more strict would allow for more 
flexibility and make it easier to automate both the process of 
generating the make.conf file and for tools to administer the USE 
variables. It may also allow for some improvements in the Portage system

as well.

Using the docs in make.conf as the starting point, I think it would make

sense to have a simple database format, or, if using python a list of 
dictionaries. For example, one entry might look like this:

use_var={"name":"esd",
          "description":"Enable enlightenment sound daemon support.",
          "priority":"OPTIONAL",
          "depends":"media-sound/esound"}

where:

priority => RECOMMENDED | REQUIRED | OPTIONAL | STANDARD |
             EXPERIMENTAL | DEPRECIATED | DONTUSE | CANNOTLIVEWITHOUT

depends  => packages required to satisfy the USE variable

Note the "depends" entry. This may allow the Portage system to become 
more flexible. Rather than just silently checking for use flags it may 
be nice to let the user know which USE variables are supported and 
possibly give the option to install supported packages, easily located 
through the "depends" field in the "database". This might serve as 
something similar to the Debian "recommended" package option. Maybe 
including a USE or OPTIONAL flag in the ebuild file that lists all of 
the possible USE options could be added.

Also, maybe adding a "--satisfyuse" flag to the ebuild/emerge command.

I know Gentoo is designed for more advanced users and what I have 
described may seem gratuitous, but I think it might make things easier 
in the long run. (Also, even advanced users can do with a _little_ 
convenience.)

It may, then, also make sense to give a little more structure to the 
optimization settings. For example:

optimization_var={
     "host":"i686",
     "chost":"i686-pc-linux-gnu",
     "cflags":"-mcpu=i686 -march=i686 -O3 -pipe",
     "cxxflags":"-mcpu=i686 -march=i686 -O3 -pipe"}

where:

host => i386 | i486 | i586 | i686 | k6 | athalon [ | ppc ]

And, for the sake of completeness, why not the FETCHCOMMAND:

fetch_cmd={
     "name":"Lukemftp",
     "command":"/usr/bin/lukemftp -s -a -o \${DISTDIR}/\${y} \${x}"}

If I recall correctly, my inspiration for all of this was when, during a

recent update, I noticed that some new USE variables were available. I 
found it annoying to see which ones I had already included (searching 
through my long and possibly overkill USE string) and if there were any 
new ones that I wanted. Then I thought, "Gee, wouldn't a nice ncurses 
interface be great -- a couple of check boxes and then I have more time 
to attend to something only a little more important?"

As this is my first (and hopefully longest) message please give me some 
feedback, both good and bad -- I can take it.

I am thoroughly enjoying Gentoo Linux. Thank you to everyone.

Regards,
Zach Forrest

_______________________________________________
gentoo-dev mailing list
gentoo-dev@gentoo.org
http://lists.gentoo.org/mailman/listinfo/gentoo-dev



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AW: [gentoo-dev] USE database?
  2001-12-03  7:41 ` AW: " Sebastian Werner
@ 2001-12-03  9:13   ` Geert Bevin
  2001-12-03 10:02     ` AW: " Sebastian Werner
  2001-12-03 11:32   ` [gentoo-dev] New ideas, USE database, sandbox & more Vitaly Kushneriuk
  1 sibling, 1 reply; 26+ messages in thread
From: Geert Bevin @ 2001-12-03  9:13 UTC (permalink / raw
  To: gentoo-dev

Hi,

the idea of a binary registry is not the path to follow imho. All system
critical settings and files should depend on as little libraries as
possible and be editable directly. This is very important in case of
system rescue. Putting these settings inside a database of some sort
really removes much of the needed flexibility and creates a magical
black box called 'system configuration' that no-one really knows and
that pretty soon can only be done through dedicate tools ... very bad.

Geert.

On Mon, 2001-12-03 at 08:41, Sebastian Werner wrote:
> Hey,
> 
> I like your idea. I have the same problems with the many variables I
> could set. Some other idea I think could be good is to store the data
> with gconf or something else (a binary registry - like windows but
> better).
> 
> Sebastian Werner
-- 
Geert Bevin
the Leaf sprl/bvba
"Use what you need"           Pierre Theunisstraat 1/47
http://www.theleaf.be         1030 Brussels
gbevin@theleaf.be             Tel & Fax +32 2 241 19 98



^ permalink raw reply	[flat|nested] 26+ messages in thread

* AW: AW: [gentoo-dev] USE database?
  2001-12-03  9:13   ` Geert Bevin
@ 2001-12-03 10:02     ` Sebastian Werner
  2001-12-03 10:12       ` Geert Bevin
  0 siblings, 1 reply; 26+ messages in thread
From: Sebastian Werner @ 2001-12-03 10:02 UTC (permalink / raw
  To: gentoo-dev

GConf for example don't depend on so many libs. I think the only not
system-lib is glib. But this lib is used also by env-update. So no big
problem. Good, the rescue Problem I agree. But it is much faster. Really
cool could it be to store all settings from /etc in binary files. But
that is not your way and not very fsh-compatible - I know. But it could
be a general idea. I don't like to have 100 files which don't follow the
same style. This is not very user-friendly. 

Some other idea is to use the sheme of ksyscoca (like KDE-2.2). It reads
text files and builds a binary cache.

Sebastian

-----Ursprüngliche Nachricht-----
Von: gentoo-dev-admin@gentoo.org [mailto:gentoo-dev-admin@gentoo.org] Im
Auftrag von Geert Bevin
Gesendet: Montag, 3. Dezember 2001 10:13
An: gentoo-dev@gentoo.org
Betreff: Re: AW: [gentoo-dev] USE database?

Hi,

the idea of a binary registry is not the path to follow imho. All system
critical settings and files should depend on as little libraries as
possible and be editable directly. This is very important in case of
system rescue. Putting these settings inside a database of some sort
really removes much of the needed flexibility and creates a magical
black box called 'system configuration' that no-one really knows and
that pretty soon can only be done through dedicate tools ... very bad.

Geert.

On Mon, 2001-12-03 at 08:41, Sebastian Werner wrote:
> Hey,
> 
> I like your idea. I have the same problems with the many variables I
> could set. Some other idea I think could be good is to store the data
> with gconf or something else (a binary registry - like windows but
> better).
> 
> Sebastian Werner
-- 
Geert Bevin
the Leaf sprl/bvba
"Use what you need"           Pierre Theunisstraat 1/47
http://www.theleaf.be         1030 Brussels
gbevin@theleaf.be             Tel & Fax +32 2 241 19 98

_______________________________________________
gentoo-dev mailing list
gentoo-dev@gentoo.org
http://lists.gentoo.org/mailman/listinfo/gentoo-dev



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AW: AW: [gentoo-dev] USE database?
  2001-12-03 10:02     ` AW: " Sebastian Werner
@ 2001-12-03 10:12       ` Geert Bevin
  2001-12-03 11:05         ` AW: " Sebastian Werner
  0 siblings, 1 reply; 26+ messages in thread
From: Geert Bevin @ 2001-12-03 10:12 UTC (permalink / raw
  To: gentoo-dev

On Mon, 2001-12-03 at 11:02, Sebastian Werner wrote:
> GConf for example don't depend on so many libs. I think the only not
> system-lib is glib. But this lib is used also by env-update. So no big
> problem. Good, the rescue Problem I agree. But it is much faster. Really

Does it? To my knowledge env-update relies on nothing else but bash and
python, note that this it a statically compiled version of python which
doesn't need any system libs. Maybe I'm overlooking something though.

> cool could it be to store all settings from /etc in binary files. But
> that is not your way and not very fsh-compatible - I know. But it could
> be a general idea. I don't like to have 100 files which don't follow the
> same style. This is not very user-friendly. 

How could you possible unify the style of all the configuration files?
This means that you'd have to track all the config formats of all
libraries and applications together with their options and write a
unified wrapper interface on top of them. I really can't see the benefit
of that, and I don't dare to imagine the sheer nightmare of trying to
maintain and update this.

> Some other idea is to use the sheme of ksyscoca (like KDE-2.2). It reads
> text files and builds a binary cache.
> 
> Sebastian
-- 
Geert Bevin
the Leaf sprl/bvba
"Use what you need"           Pierre Theunisstraat 1/47
http://www.theleaf.be         1030 Brussels
gbevin@theleaf.be             Tel & Fax +32 2 241 19 98



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AW: AW: AW: [gentoo-dev] USE database?
  2001-12-03 11:05         ` AW: " Sebastian Werner
@ 2001-12-03 11:05           ` Geert Bevin
  2001-12-03 11:26             ` AW: " Sebastian Werner
  0 siblings, 1 reply; 26+ messages in thread
From: Geert Bevin @ 2001-12-03 11:05 UTC (permalink / raw
  To: gentoo-dev

So you want to patch every application or library to use a centralized
solution?

On Mon, 2001-12-03 at 12:05, Sebastian Werner wrote:
> Ok ok, I don't want to write a wrapper. This is not a solution. I want
> that the programs natively using this database. Ok much work but it
> could be a nice future I think.
> 
> Sebastian
-- 
Geert Bevin
the Leaf sprl/bvba
"Use what you need"           Pierre Theunisstraat 1/47
http://www.theleaf.be         1030 Brussels
gbevin@theleaf.be             Tel & Fax +32 2 241 19 98



^ permalink raw reply	[flat|nested] 26+ messages in thread

* AW: AW: AW: [gentoo-dev] USE database?
  2001-12-03 10:12       ` Geert Bevin
@ 2001-12-03 11:05         ` Sebastian Werner
  2001-12-03 11:05           ` Geert Bevin
  0 siblings, 1 reply; 26+ messages in thread
From: Sebastian Werner @ 2001-12-03 11:05 UTC (permalink / raw
  To: gentoo-dev

Ok ok, I don't want to write a wrapper. This is not a solution. I want
that the programs natively using this database. Ok much work but it
could be a nice future I think.

Sebastian

-----Ursprüngliche Nachricht-----
Von: gentoo-dev-admin@gentoo.org [mailto:gentoo-dev-admin@gentoo.org] Im
Auftrag von Geert Bevin
Gesendet: Montag, 3. Dezember 2001 11:12
An: gentoo-dev@gentoo.org
Betreff: Re: AW: AW: [gentoo-dev] USE database?

On Mon, 2001-12-03 at 11:02, Sebastian Werner wrote:
> GConf for example don't depend on so many libs. I think the only not
> system-lib is glib. But this lib is used also by env-update. So no big
> problem. Good, the rescue Problem I agree. But it is much faster.
Really

Does it? To my knowledge env-update relies on nothing else but bash and
python, note that this it a statically compiled version of python which
doesn't need any system libs. Maybe I'm overlooking something though.

> cool could it be to store all settings from /etc in binary files. But
> that is not your way and not very fsh-compatible - I know. But it
could
> be a general idea. I don't like to have 100 files which don't follow
the
> same style. This is not very user-friendly. 

How could you possible unify the style of all the configuration files?
This means that you'd have to track all the config formats of all
libraries and applications together with their options and write a
unified wrapper interface on top of them. I really can't see the benefit
of that, and I don't dare to imagine the sheer nightmare of trying to
maintain and update this.

> Some other idea is to use the sheme of ksyscoca (like KDE-2.2). It
reads
> text files and builds a binary cache.
> 
> Sebastian
-- 
Geert Bevin
the Leaf sprl/bvba
"Use what you need"           Pierre Theunisstraat 1/47
http://www.theleaf.be         1030 Brussels
gbevin@theleaf.be             Tel & Fax +32 2 241 19 98

_______________________________________________
gentoo-dev mailing list
gentoo-dev@gentoo.org
http://lists.gentoo.org/mailman/listinfo/gentoo-dev



^ permalink raw reply	[flat|nested] 26+ messages in thread

* AW: AW: AW: AW: [gentoo-dev] USE database?
  2001-12-03 11:05           ` Geert Bevin
@ 2001-12-03 11:26             ` Sebastian Werner
  0 siblings, 0 replies; 26+ messages in thread
From: Sebastian Werner @ 2001-12-03 11:26 UTC (permalink / raw
  To: gentoo-dev

Ok, his isn't anymore gentoo-specific. No, I didn't want to patch them.
I want that they use this database it in the future. ;-)

This wish never becomes reality. I know. :-(

Sebastian

-----Ursprüngliche Nachricht-----
Von: gentoo-dev-admin@gentoo.org [mailto:gentoo-dev-admin@gentoo.org] Im
Auftrag von Geert Bevin
Gesendet: Montag, 3. Dezember 2001 12:05
An: gentoo-dev@gentoo.org
Betreff: Re: AW: AW: AW: [gentoo-dev] USE database?

So you want to patch every application or library to use a centralized
solution?

On Mon, 2001-12-03 at 12:05, Sebastian Werner wrote:
> Ok ok, I don't want to write a wrapper. This is not a solution. I want
> that the programs natively using this database. Ok much work but it
> could be a nice future I think.
> 
> Sebastian
-- 
Geert Bevin
the Leaf sprl/bvba
"Use what you need"           Pierre Theunisstraat 1/47
http://www.theleaf.be         1030 Brussels
gbevin@theleaf.be             Tel & Fax +32 2 241 19 98

_______________________________________________
gentoo-dev mailing list
gentoo-dev@gentoo.org
http://lists.gentoo.org/mailman/listinfo/gentoo-dev



^ permalink raw reply	[flat|nested] 26+ messages in thread

* [gentoo-dev] New ideas, USE database, sandbox & more
  2001-12-03  7:41 ` AW: " Sebastian Werner
  2001-12-03  9:13   ` Geert Bevin
@ 2001-12-03 11:32   ` Vitaly Kushneriuk
  2001-12-03 11:48     ` Geert Bevin
  2001-12-03 14:01     ` Joshua Pierre
  1 sibling, 2 replies; 26+ messages in thread
From: Vitaly Kushneriuk @ 2001-12-03 11:32 UTC (permalink / raw
  To: gentoo-dev

On Mon, 2001-12-03 at 09:41, Sebastian Werner wrote:
> Hey,
> 
> I like your idea. I have the same problems with the many variables I
> could set. Some other idea I think could be good is to store the data
> with gconf or something else (a binary registry - like windows but
> better).
> 
> Sebastian Werner

I like the idea too, but I don't think we should use gconf.
This information should be stored in clear text for easy
inspection/editing.

Some more ideas:

Note before I start: I can participate in development of my proposals,
but I want to be sure that you guys like the ideas. Please comment...

1)Actualy used features should be stored ,so that if 
  I install a package which can use FEATURE1 and FEATURE2, but
  only FEATURE1 is available(and used) at the build time, I'd like to be
  notified when I install another package that provides FEATURE2, that 
  I can remerge the first package for additional functionality.
  As all USES available during build are already stored in /var/db
  We only need to add list of possible USES in .ebuild.
  
2)Long descriptions should be added.

3)emerge should search for package in category dirs. So that
  "emerge gcc" as "emerge sys-devel/gcc" 

4)ebuilds must be simplified! Most packages can be build by rpm macros

  %setup
  %configure
  %make
  %makeinstall

  We should provide such macros for our builds and use them in the
  default implementation for unpack/compile/install functions.
  So that most ebuilds will contain only URL/DESCRIPTION etc.

5)Compile and install logs should be stored for future inspection.
  Should be realy simple to implement. Just redirect sub shell to 
  "| tee <logfilename>. Or even "> logfilename" if emerge called with
  --silent flag.

6)Why bother with the sendbox and not just compile and install nonroot?
  Some packages will even refuse to be built by root. Take a look at
  rpm build system. Any reasonably good srpm will compile as non root.

7)And while we at it, why not using rpm as underlying package system
  with Portage metadata added to the rpm file. Yes, I know, rpm is 
  considered "evil" by many linux hackers alike. I don't see a real
  reason why. If rpm complains about some dependency stuff, you can 
  allways run 
      "rpm --force --nodeps" 
  to make it look like just a tarball. Still there must be a reason why
it complains, so some action should be taken (i.e. other package
  removed/recompiled etc), and that exectly what Portage can 
  take care of. And, btw, rpm config file protection is realy great.
  ( well, we can do the same in Portage, but why reinvent the wheel?)
  And yes, I VERY like to type 'rpm -qf <filename>' to know 
  which package installed this file. While an average Gentoo admin knows
  her system better then an admin using binary distribution, it's
  impossible/impractical to know EVERY file on the system. And this is
  only one of the many useful rpm queries I'm used to like. So here how
  I see the integration:
    * Compilation and installation are performed as usual
      su'ed to some "build" user (see 6).
    * All Portage metadata is "installed" into
      <build_install_root>/var/db
      No need for CONTENTS/CATEGORY/LICENSE/PROVIDE/RDEPEND
    * src_files() function is called to generate rpm %files list.
      auto_files() function called from default src_files() will
      scan install root directory and prepend all files in /etc
      with %conf, and all files in */doc/, */man/ or */info/ with
      %doc. Well, actualy some configurable list can be used for config
      directories.
      If, for some package, this function fails for some file,
      the package files() function can easily fix it by something like:
          echo %defattr(-, bin, bin)
          auto_files | grep -v 'myconfig' | grep -v devattr
          echo %conf %attr(-, bin, wheel) /mydir/myconfig
      I have auto_file implementation I used to build rpms 
      when I used RedHat.

    * spec file is generated ( we allready have that )
      and all the files packaged into rpm ( in future versions we even
      can create rpm directly using rpmlib api )

    * rpm package is installed by "rpm -Uvh"
      This is the ONLY stage performed as root.


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] New ideas, USE database, sandbox & more
  2001-12-03 11:32   ` [gentoo-dev] New ideas, USE database, sandbox & more Vitaly Kushneriuk
@ 2001-12-03 11:48     ` Geert Bevin
  2001-12-03 12:55       ` Vitaly Kushneriuk
  2001-12-03 14:01     ` Joshua Pierre
  1 sibling, 1 reply; 26+ messages in thread
From: Geert Bevin @ 2001-12-03 11:48 UTC (permalink / raw
  To: gentoo-dev

On Mon, 2001-12-03 at 12:32, Vitaly Kushneriuk wrote:
> 1)Actualy used features should be stored ,so that if 
>   I install a package which can use FEATURE1 and FEATURE2, but
>   only FEATURE1 is available(and used) at the build time, I'd like to be
>   notified when I install another package that provides FEATURE2, that 
>   I can remerge the first package for additional functionality.
>   As all USES available during build are already stored in /var/db
>   We only need to add list of possible USES in .ebuild.

I like the idea of feature provision notification.

> 2)Long descriptions should be added.

The problem with long descriptions is that they should be updated
consistantly. Also, package authors tend to neglect them. It's a useful
addition, but I can only see it usefulness if some sort of graphical
package manager were available.

> 3)emerge should search for package in category dirs. So that
>   "emerge gcc" as "emerge sys-devel/gcc" 
> 
> 4)ebuilds must be simplified! Most packages can be build by rpm macros
> 
>   %setup
>   %configure
>   %make
>   %makeinstall
> 
>   We should provide such macros for our builds and use them in the
>   default implementation for unpack/compile/install functions.
>   So that most ebuilds will contain only URL/DESCRIPTION etc.
> 
> 5)Compile and install logs should be stored for future inspection.
>   Should be realy simple to implement. Just redirect sub shell to 
>   "| tee <logfilename>. Or even "> logfilename" if emerge called with
>   --silent flag.
> 
> 6)Why bother with the sendbox and not just compile and install nonroot?
>   Some packages will even refuse to be built by root. Take a look at
>   rpm build system. Any reasonably good srpm will compile as non root.

Because non-root and sandbox work together. There are also a number of
ebuilds that need to be root before being able to install. Working in
non root fixes the access right to paths statically. A sandbox does this
dynamically, offering a much more flexible environment. Some ebuilds
need also to be able to switch to other users and perform initialization
as the other user. A nice feature of the sandbox is that additionally to
portage, the ebuild package system can be used to create much more
complex personal packages. For example, we have ebuilds for each of our
clients and projects, automating installing and configuration. I
certainly don't want any files of one client installation to 'leak'
accidentally into common ground or even worse, into another's
installation. Using the sandbox its possible to change the allowed path
for each package (and even during the ebuild) and offer that kind of
protection.
-- 
Geert Bevin
the Leaf sprl/bvba
"Use what you need"           Pierre Theunisstraat 1/47
http://www.theleaf.be         1030 Brussels
gbevin@theleaf.be             Tel & Fax +32 2 241 19 98



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] New ideas, USE database, sandbox & more
  2001-12-03 11:48     ` Geert Bevin
@ 2001-12-03 12:55       ` Vitaly Kushneriuk
  0 siblings, 0 replies; 26+ messages in thread
From: Vitaly Kushneriuk @ 2001-12-03 12:55 UTC (permalink / raw
  To: gentoo-dev

 
> The problem with long descriptions is that they should be updated
> consistantly. Also, package authors tend to neglect them. It's a useful
> addition, but I can only see it usefulness if some sort of graphical
> package manager were available.
>

Not realy. I'd like to be able to get some more information
about any of the ebuilds in /usr/portage. Like:
[/root]# emerge --whatis gcc
Summary     : Various compilers (C, C++, Objective-C, ...)
Description :
A compiler aimed at integrating all the optimizations and features
necessary for a high-performance and stable development
environment. You'll need this package in order to compile C/C++ code.
[/root]#

The description may be a SEPARATE file, so that future ebuilds for
the same package will use just latest description file available

> > 6)Why bother with the sendbox and not just compile and install nonroot?
> >   Some packages will even refuse to be built by root. Take a look at
> >   rpm build system. Any reasonably good srpm will compile as non root.
> 
> Because non-root and sandbox work together. There are also a number of
> ebuilds that need to be root before being able to install. Working in
> non root fixes the access right to paths statically. A sandbox does this
> dynamically, offering a much more flexible environment. Some ebuilds
> need also to be able to switch to other users and perform initialization
> as the other user. A nice feature of the sandbox is that additionally to
> portage, the ebuild package system can be used to create much more
> complex personal packages. For example, we have ebuilds for each of our
> clients and projects, automating installing and configuration. I
> certainly don't want any files of one client installation to 'leak'
> accidentally into common ground or even worse, into another's
> installation. Using the sandbox its possible to change the allowed path
> for each package (and even during the ebuild) and offer that kind of
> protection.
Entire binary distributions compile as non root, so I think it should
not be a problem. To prevent "leaking" of files, just set up reasonable 
access rigts, then run as user, and you'll not be able to write to
other user directory etc. Then , again, Portage should not be 
MOST-GENERIC-kNOW-HOW-TO-BUILD-EVERYTHING-COOLEST-THING-IN-THE-WORLD :-)
It's just a tool to compile Linux system and keep it up to date.
It should not be over complicated to support every wierd configuration.
Things like you described sound like more suitable
task for "make" or "cook" :-)
We better make Portage more usable for all SAs, which includes much
simplified ebuild creation. With some effort, we can make it build from
a little "rewriten" rpm spec file, which can be 
extracted from any binary distro. So that if you see some new cool
proggy, providing rpm download, or just a plain spec inside the tgz.
It will take only few minutes to convert it to Portage format and build.


Regards,
	Vitaly.




^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] New ideas, USE database, sandbox & more
  2001-12-03 11:32   ` [gentoo-dev] New ideas, USE database, sandbox & more Vitaly Kushneriuk
  2001-12-03 11:48     ` Geert Bevin
@ 2001-12-03 14:01     ` Joshua Pierre
  2001-12-03 16:06       ` Vitaly Kushneriuk
  2001-12-03 16:28       ` Daniel Robbins
  1 sibling, 2 replies; 26+ messages in thread
From: Joshua Pierre @ 2001-12-03 14:01 UTC (permalink / raw
  To: gentoo-dev

On Mon, Dec 03, 2001 at 01:32:13PM +0200 or thereabouts, Vitaly Kushneriuk wrote:
> 2)Long descriptions should be added.

Yes this will help, I believe Debian uses somethingalong the lines.

> 3)emerge should search for package in category dirs. So that
>   "emerge gcc" as "emerge sys-devel/gcc" 

This would be really cool, I imagine it would be hard to add to portage. (Comments drobbins?)

> 5)Compile and install logs should be stored for future inspection.
>   Should be realy simple to implement. Just redirect sub shell to 
>   "| tee <logfilename>. Or even "> logfilename" if emerge called with
>   --silent flag.

Again, this would be really good for backtracking failed builds.

Some really good ideas here but I am not sure it will all fit in with portage.

Cheers,

-- 
Joshua Pierre
Developer & Release Technician
Themes.Org -- Open Source Interface Enhancement


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] New ideas, USE database, sandbox & more
  2001-12-03 14:01     ` Joshua Pierre
@ 2001-12-03 16:06       ` Vitaly Kushneriuk
  2001-12-03 16:28       ` Daniel Robbins
  1 sibling, 0 replies; 26+ messages in thread
From: Vitaly Kushneriuk @ 2001-12-03 16:06 UTC (permalink / raw
  To: gentoo-dev

> > 3)emerge should search for package in category dirs. So that
> >   "emerge gcc" as "emerge sys-devel/gcc" 
> 
> This would be really cool, I imagine it would be hard to add to portage. (Comments drobbins?)

Not at all It should be less then 20 lines of code. like that (in shell, not checked ):

if [ ! -f $package ] ; then 
  for f in /usr/portage/*/$package ; do
    if [ -d $f ] ; then
       $package=`echo $f | sed 's:^/usr/portage/::'`
       break
    fi
  done
fi


> > 5)Compile and install logs should be stored for future inspection.
> >   Should be realy simple to implement. Just redirect sub shell to 
> >   "| tee <logfilename>. Or even "> logfilename" if emerge called with
> >   --silent flag.
> 
> Again, this would be really good for backtracking failed builds.
> 
> Some really good ideas here but I am not sure it will all fit in with portage.
> 
Again, realy easy... I'll do it later if no one volontiers.

    Vitaly.


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] New ideas, USE database, sandbox & more
  2001-12-03 14:01     ` Joshua Pierre
  2001-12-03 16:06       ` Vitaly Kushneriuk
@ 2001-12-03 16:28       ` Daniel Robbins
  2001-12-03 18:00         ` Vitaly Kushneriuk
  1 sibling, 1 reply; 26+ messages in thread
From: Daniel Robbins @ 2001-12-03 16:28 UTC (permalink / raw
  To: gentoo-dev

On Mon, Dec 03, 2001 at 10:01:47PM +0800, Joshua Pierre wrote:

> This would be really cool, I imagine it would be hard to add to portage.
> (Comments drobbins?)

"emerge gcc" would be easy to add.  Not a priority for me atm.  Is it really
so hard to type "emerge sys-devel/gcc"?
> 
> > 5)Compile and install logs should be stored for future inspection.
> >   Should be realy simple to implement. Just redirect sub shell to 
> >   "| tee <logfilename>. Or even "> logfilename" if emerge called with
> >   --silent flag.
> 
> Again, this would be really good for backtracking failed builds.

There is a command called "script" that can be used to log everything that
happens on the console.  This logging issue comes up periodically, and
personally, I think it's easier to use our already existing command.  Type "man
script".  Basically, "script" gives you a new shell where everything is logged
to a typescript file.  When you exit the new shell, scripting is turned off.
The disadvantage of this approach is that scripting does not happen on a
per-package basis.  But I haven't seen any Gentoo Linux developers actually
requesting enhanced logging capabilities.  So again, not a high priority.

Best Regards,

-- 
Daniel Robbins                                  <drobbins@gentoo.org>
Chief Architect/President                       http://www.gentoo.org 
Gentoo Technologies, Inc.


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] USE database?
  2001-12-03  1:06 [gentoo-dev] USE database? Zach Forrest
  2001-12-03  7:41 ` AW: " Sebastian Werner
@ 2001-12-03 16:48 ` Daniel Robbins
  2001-12-06  6:01   ` Mikael Hallendal
  1 sibling, 1 reply; 26+ messages in thread
From: Daniel Robbins @ 2001-12-03 16:48 UTC (permalink / raw
  To: gentoo-dev

On Sun, Dec 02, 2001 at 05:06:53PM -0800, Zach Forrest wrote:
> One thing I think needs some refinement is the USE system. I was 
> thinking that using a format that is more strict would allow for more 
> flexibility and make it easier to automate both the process of 
> generating the make.conf file and for tools to administer the USE 
> variables. It may also allow for some improvements in the Portage system 
> as well.

You're right, our USE system needs refinement, and we are currently
fleshing out details on how to do this.  I agree that we may need a 
master repository of USE variables, and I can code Portage to complain
about "invalid USE variables" if they aren't defined properly.  This
should give everyone the impetus to update a global USE variable 
definition file, making everyone's life easier.  Good idea!

> Using the docs in make.conf as the starting point, I think it would make 
> sense to have a simple database format, or, if using python a list of 
> dictionaries. For example, one entry might look like this:
> 
> use_var={"name":"esd",
>          "description":"Enable enlightenment sound daemon support.",
>          "priority":"OPTIONAL",
>          "depends":"media-sound/esound"}

Sounds like a good plan.  I haven't considered having a "depends" for
every USE variable, but it could come in handy if only for informational
purposes.

> Also, maybe adding a "--satisfyuse" flag to the ebuild/emerge command.

Good idea.

> I know Gentoo is designed for more advanced users and what I have 
> described may seem gratuitous, but I think it might make things easier 
> in the long run. (Also, even advanced users can do with a _little_ 
> convenience.)

Agreed.

> It may, then, also make sense to give a little more structure to the 
> optimization settings. For example:
> 
> optimization_var={
>     "host":"i686",
>     "chost":"i686-pc-linux-gnu",
>     "cflags":"-mcpu=i686 -march=i686 -O3 -pipe",
>     "cxxflags":"-mcpu=i686 -march=i686 -O3 -pipe"}

It would make my life easier if we would use python-based configuration
files.  Right now, they're parsed.  But being able to define dictionaries
is really appealing to me right now :)

> fetch_cmd={
>     "name":"Lukemftp",
>     "command":"/usr/bin/lukemftp -s -a -o \${DISTDIR}/\${y} \${x}"}

Just the idea of using dictionaries for configuration is sounding good
to me right now! :)

> I am thoroughly enjoying Gentoo Linux. Thank you to everyone.

You're welcome.  And thanks for the thought-provoking suggestions :)

-- 
Daniel Robbins                                  <drobbins@gentoo.org>
Chief Architect/President                       http://www.gentoo.org 
Gentoo Technologies, Inc.


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] New ideas, USE database, sandbox & more
  2001-12-03 16:28       ` Daniel Robbins
@ 2001-12-03 18:00         ` Vitaly Kushneriuk
  0 siblings, 0 replies; 26+ messages in thread
From: Vitaly Kushneriuk @ 2001-12-03 18:00 UTC (permalink / raw
  To: gentoo-dev

On Mon, 2001-12-03 at 18:28, Daniel Robbins wrote:
> On Mon, Dec 03, 2001 at 10:01:47PM +0800, Joshua Pierre wrote:
> 
> > This would be really cool, I imagine it would be hard to add to portage.
> > (Comments drobbins?)
> 
> "emerge gcc" would be easy to add.  Not a priority for me atm.  Is it really
> so hard to type "emerge sys-devel/gcc"?

It is easy, but may be really annoing some times :-).

And btw, on one forum, I saw it among the reasons that guy used other
source based distribution. *laugh*


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] USE database?
  2001-12-03 16:48 ` [gentoo-dev] USE database? Daniel Robbins
@ 2001-12-06  6:01   ` Mikael Hallendal
  2001-12-06 18:12     ` Zach Forrest
  0 siblings, 1 reply; 26+ messages in thread
From: Mikael Hallendal @ 2001-12-06  6:01 UTC (permalink / raw
  To: gentoo-dev

mån 2001-12-03 klockan 17.48 skrev Daniel Robbins:
> On Sun, Dec 02, 2001 at 05:06:53PM -0800, Zach Forrest wrote:

> > It may, then, also make sense to give a little more structure to the 
> > optimization settings. For example:
> > 
> > optimization_var={
> >     "host":"i686",
> >     "chost":"i686-pc-linux-gnu",
> >     "cflags":"-mcpu=i686 -march=i686 -O3 -pipe",
> >     "cxxflags":"-mcpu=i686 -march=i686 -O3 -pipe"}
> 
> It would make my life easier if we would use python-based configuration
> files.  Right now, they're parsed.  But being able to define dictionaries
> is really appealing to me right now :)

The problem with this is that it's harder to edit in a regular browser,
not much hard but still, somewhat harder.
Also, it's quite nice to be able to override with regular environment
variables. I guess this can be done no matter..

About using GConf, imho it's actually not a totally bad idea. It is
thought of as being for the entire system (will never happend though).
Currently it has some weird deps (like gnome-libs->gtk+->X11) which is
no good.

It does not store it's configuration in a binary database, it's in
xml-files in /etc/gconf. Anyway, I'm more in favor of something that's
easily editable in a normal text editor.

Regards,
  Mikael Hallendal

-- 
Mikael Hallendal              http://micke.hallendal.net/
Stockholm, Sweden             Cell: +46 (0)709 718 918






^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] USE database?
  2001-12-06  6:01   ` Mikael Hallendal
@ 2001-12-06 18:12     ` Zach Forrest
  2001-12-06 20:38       ` Mikael Hallendal
  0 siblings, 1 reply; 26+ messages in thread
From: Zach Forrest @ 2001-12-06 18:12 UTC (permalink / raw
  To: gentoo-dev

Before using python as an example, I had actually played with the idea 
of using XML. Any thoughts on this? I know that compared to a plain text 
file both of these notions seem somewhat cumbersome, but there are a 
couple of arguments for using a more structured approach. One, 
programatically handling the data is easier. Using either python or XML 
(and a parser) allows named access rather positional access to the 
fields. It also makes the definition of "records" more clear and easier 
to understand for new developers (i.e. me). It wouldn't be too difficult 
to parse XML (even into a dictionary).

As far as GConf is concerned, I think that the base system should have 
as few dependencies as possible. Python is already required, and, in my 
opinion, with its XML capabilities (or just using dictionaries) I 
believe a solution along these lines would be preferable.

Zach.


Mikael Hallendal wrote:

> mån 2001-12-03 klockan 17.48 skrev Daniel Robbins:
> 
>>On Sun, Dec 02, 2001 at 05:06:53PM -0800, Zach Forrest wrote:
>>
> 
>>>It may, then, also make sense to give a little more structure to the 
>>>optimization settings. For example:
>>>
>>>optimization_var={
>>>    "host":"i686",
>>>    "chost":"i686-pc-linux-gnu",
>>>    "cflags":"-mcpu=i686 -march=i686 -O3 -pipe",
>>>    "cxxflags":"-mcpu=i686 -march=i686 -O3 -pipe"}
>>>
>>It would make my life easier if we would use python-based configuration
>>files.  Right now, they're parsed.  But being able to define dictionaries
>>is really appealing to me right now :)
>>
> 
> The problem with this is that it's harder to edit in a regular browser,
> not much hard but still, somewhat harder.
> Also, it's quite nice to be able to override with regular environment
> variables. I guess this can be done no matter..
> 
> About using GConf, imho it's actually not a totally bad idea. It is
> thought of as being for the entire system (will never happend though).
> Currently it has some weird deps (like gnome-libs->gtk+->X11) which is
> no good.
> 
> It does not store it's configuration in a binary database, it's in
> xml-files in /etc/gconf. Anyway, I'm more in favor of something that's
> easily editable in a normal text editor.
> 
> Regards,
>   Mikael Hallendal
> 
> 




^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] USE database?
  2001-12-06 18:12     ` Zach Forrest
@ 2001-12-06 20:38       ` Mikael Hallendal
  2001-12-06 22:33         ` Zach Forrest
  0 siblings, 1 reply; 26+ messages in thread
From: Mikael Hallendal @ 2001-12-06 20:38 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

tor 2001-12-06 klockan 19.12 skrev Zach Forrest:
> Before using python as an example, I had actually played with the idea 
> of using XML. Any thoughts on this? I know that compared to a plain text 
> file both of these notions seem somewhat cumbersome, but there are a 
> couple of arguments for using a more structured approach. One, 
> programatically handling the data is easier. Using either python or XML 
> (and a parser) allows named access rather positional access to the 
> fields. It also makes the definition of "records" more clear and easier 
> to understand for new developers (i.e. me). It wouldn't be too difficult 
> to parse XML (even into a dictionary).

Yes, I thought about using XML too, as you say, for parsing the file
it'll be better since we don't narrow it down to python. Any language
that can parse XML (most) can be used for tools and such. 

The problem is that writing things in XML will be even harder than the
pretty clean syntax you proposed.
 
> As far as GConf is concerned, I think that the base system should have 
> as few dependencies as possible. Python is already required, and, in my 
> opinion, with its XML capabilities (or just using dictionaries) I 
> believe a solution along these lines would be preferable.

Yes, GConf is IMHO not an option today, perhaps in the future when it:
1) is more stable/tested for these kind of things.
2) has nice tools for editing the contents.

Regards,
  Mikael Hallendal
 
-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] USE database?
  2001-12-06 20:38       ` Mikael Hallendal
@ 2001-12-06 22:33         ` Zach Forrest
  2001-12-06 23:40           ` Daniel Robbins
  2001-12-07 19:28           ` Sebastian Werner
  0 siblings, 2 replies; 26+ messages in thread
From: Zach Forrest @ 2001-12-06 22:33 UTC (permalink / raw
  To: gentoo-dev

 >
 > The problem is that writing things in XML will be even harder than the
 > pretty clean syntax you proposed.
 >

Maybe a little more laborious, but not really that hard. Take this for 
example:

use_var={"name":"esd",
          "description":"Enable enlightenment sound daemon support.",
          "priority":"OPTIONAL",
          "depends":"media-sound/esound"}

To write this in XML it would look like this:

<usedatabase>

   <useflag name=esd>
     <description>Enable enlightenment sound daemon support</description>
     <priority>OPTIONAL</priority>
     <depends>media-sound/esound</depends>
   </useflag>

</usedatabase>

(OK, not quite as _pretty_, but I've seen worse. The syntax, though, is 
clean.)

Also, I don't think it would be too painful because it's not like 
someone would have to spend all day editing/adding entries. It would be 
pretty easy to write a script to prompt for the name/desc/etc. and 
generate the  XML.

Benefits of using XML also include:
- Rules, such as declaring "priority" flags, can be created in and 
enforced by a schema.
- Validation in general.
- Consistent formatting would also be easy with XML.
- Flexibility.

(Not to sound like a commercial.)



Mikael Hallendal wrote:

> tor 2001-12-06 klockan 19.12 skrev Zach Forrest:
> 
>>Before using python as an example, I had actually played with the idea 
>>of using XML. Any thoughts on this? I know that compared to a plain text 
>>file both of these notions seem somewhat cumbersome, but there are a 
>>couple of arguments for using a more structured approach. One, 
>>programatically handling the data is easier. Using either python or XML 
>>(and a parser) allows named access rather positional access to the 
>>fields. It also makes the definition of "records" more clear and easier 
>>to understand for new developers (i.e. me). It wouldn't be too difficult 
>>to parse XML (even into a dictionary).
>>
> 
> Yes, I thought about using XML too, as you say, for parsing the file
> it'll be better since we don't narrow it down to python. Any language
> that can parse XML (most) can be used for tools and such. 
> 
> The problem is that writing things in XML will be even harder than the
> pretty clean syntax you proposed.

> 
>>As far as GConf is concerned, I think that the base system should have 
>>as few dependencies as possible. Python is already required, and, in my 
>>opinion, with its XML capabilities (or just using dictionaries) I 
>>believe a solution along these lines would be preferable.
>>
> 
> Yes, GConf is IMHO not an option today, perhaps in the future when it:
> 1) is more stable/tested for these kind of things.
> 2) has nice tools for editing the contents.
> 
> Regards,
>   Mikael Hallendal
>  
> 




^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] USE database?
  2001-12-06 22:33         ` Zach Forrest
@ 2001-12-06 23:40           ` Daniel Robbins
  2001-12-06 23:52             ` Zach Forrest
  2001-12-07 19:28           ` Sebastian Werner
  1 sibling, 1 reply; 26+ messages in thread
From: Daniel Robbins @ 2001-12-06 23:40 UTC (permalink / raw
  To: gentoo-dev

On Thu, Dec 06, 2001 at 02:33:21PM -0800, Zach Forrest wrote:

> Benefits of using XML also include:

We're not going to be using XML. :)

-- 
Daniel Robbins                                  <drobbins@gentoo.org>
Chief Architect/President                       http://www.gentoo.org 
Gentoo Technologies, Inc.


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] USE database?
  2001-12-06 23:40           ` Daniel Robbins
@ 2001-12-06 23:52             ` Zach Forrest
  0 siblings, 0 replies; 26+ messages in thread
From: Zach Forrest @ 2001-12-06 23:52 UTC (permalink / raw
  To: gentoo-dev

ok

Daniel Robbins wrote:

> On Thu, Dec 06, 2001 at 02:33:21PM -0800, Zach Forrest wrote:
> 
> 
>>Benefits of using XML also include:
>>
> 
> We're not going to be using XML. :)
> 
> 




^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] USE database?
  2001-12-06 22:33         ` Zach Forrest
  2001-12-06 23:40           ` Daniel Robbins
@ 2001-12-07 19:28           ` Sebastian Werner
  2001-12-07 21:39             ` Daniel Robbins
  1 sibling, 1 reply; 26+ messages in thread
From: Sebastian Werner @ 2001-12-07 19:28 UTC (permalink / raw
  To: gentoo-dev

I like it more to place in in attrib tags:

<usedatabase>

<package name="esd" priority="OPTIONAL" depends="media-sound/esound">Enable enlightenment sound daemon support</package>

</usedatabase>

Why not XML... it's really nice to edit i think

Regards 
Sebastian

06.12.2001 23:33:21, Zach Forrest <diatribe@shaw.ca> wrote:

> >
> > The problem is that writing things in XML will be even harder than the
> > pretty clean syntax you proposed.
> >
>
>Maybe a little more laborious, but not really that hard. Take this for 
>example:
>
>use_var={"name":"esd",
>          "description":"Enable enlightenment sound daemon support.",
>          "priority":"OPTIONAL",
>          "depends":"media-sound/esound"}
>
>To write this in XML it would look like this:
>
><usedatabase>
>
>   <useflag name=esd>
>     <description>Enable enlightenment sound daemon support</description>
>     <priority>OPTIONAL</priority>
>     <depends>media-sound/esound</depends>
>   </useflag>
>
></usedatabase>
>
>(OK, not quite as _pretty_, but I've seen worse. The syntax, though, is 
>clean.)
>
>Also, I don't think it would be too painful because it's not like 
>someone would have to spend all day editing/adding entries. It would be 
>pretty easy to write a script to prompt for the name/desc/etc. and 
>generate the  XML.
>
>Benefits of using XML also include:
>- Rules, such as declaring "priority" flags, can be created in and 
>enforced by a schema.
>- Validation in general.
>- Consistent formatting would also be easy with XML.
>- Flexibility.
>
>(Not to sound like a commercial.)
>
>
>
>Mikael Hallendal wrote:
>
>> tor 2001-12-06 klockan 19.12 skrev Zach Forrest:
>> 
>>>Before using python as an example, I had actually played with the idea 
>>>of using XML. Any thoughts on this? I know that compared to a plain text 
>>>file both of these notions seem somewhat cumbersome, but there are a 
>>>couple of arguments for using a more structured approach. One, 
>>>programatically handling the data is easier. Using either python or XML 
>>>(and a parser) allows named access rather positional access to the 
>>>fields. It also makes the definition of "records" more clear and easier 
>>>to understand for new developers (i.e. me). It wouldn't be too difficult 
>>>to parse XML (even into a dictionary).
>>>
>> 
>> Yes, I thought about using XML too, as you say, for parsing the file
>> it'll be better since we don't narrow it down to python. Any language
>> that can parse XML (most) can be used for tools and such. 
>> 
>> The problem is that writing things in XML will be even harder than the
>> pretty clean syntax you proposed.
>
>> 
>>>As far as GConf is concerned, I think that the base system should have 
>>>as few dependencies as possible. Python is already required, and, in my 
>>>opinion, with its XML capabilities (or just using dictionaries) I 
>>>believe a solution along these lines would be preferable.
>>>
>> 
>> Yes, GConf is IMHO not an option today, perhaps in the future when it:
>> 1) is more stable/tested for these kind of things.
>> 2) has nice tools for editing the contents.
>> 
>> Regards,
>>   Mikael Hallendal
>>  
>> 
>
>
>_______________________________________________
>gentoo-dev mailing list
>gentoo-dev@gentoo.org
>http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>





^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] USE database?
  2001-12-07 19:28           ` Sebastian Werner
@ 2001-12-07 21:39             ` Daniel Robbins
  2001-12-07 21:43               ` Geert Bevin
  2001-12-08  1:44               ` Mikael Hallendal
  0 siblings, 2 replies; 26+ messages in thread
From: Daniel Robbins @ 2001-12-07 21:39 UTC (permalink / raw
  To: gentoo-dev

On Fri, Dec 07, 2001 at 08:28:05PM +0100, Sebastian Werner wrote:

> Why not XML... it's really nice to edit i think

Because XML requires a whole new bloated, slow parser, and the python
parser is fast and the syntax is lean and mean.  Also, if we port to
C, it would be more effective to support "python-style" dictionary
definitions that include and entire XML parser.  Also consider that
XML has no equivalent of python dictionaries.

-- 
Daniel Robbins                                  <drobbins@gentoo.org>
Chief Architect/President                       http://www.gentoo.org 
Gentoo Technologies, Inc.


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] USE database?
  2001-12-07 21:39             ` Daniel Robbins
@ 2001-12-07 21:43               ` Geert Bevin
  2001-12-08  1:44               ` Mikael Hallendal
  1 sibling, 0 replies; 26+ messages in thread
From: Geert Bevin @ 2001-12-07 21:43 UTC (permalink / raw
  To: gentoo-dev

Well it's maybe nice to edit in an xml editor, but as plain text it's
quite confusing.

On Fri, 2001-12-07 at 22:39, Daniel Robbins wrote:
> On Fri, Dec 07, 2001 at 08:28:05PM +0100, Sebastian Werner wrote:
> 
> > Why not XML... it's really nice to edit i think
> 
> Because XML requires a whole new bloated, slow parser, and the python
> parser is fast and the syntax is lean and mean.  Also, if we port to
> C, it would be more effective to support "python-style" dictionary
> definitions that include and entire XML parser.  Also consider that
> XML has no equivalent of python dictionaries.
-- 
Geert Bevin
the Leaf sprl/bvba
"Use what you need"           Pierre Theunisstraat 1/47
http://www.theleaf.be         1030 Brussels
gbevin@theleaf.be             Tel & Fax +32 2 241 19 98



^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [gentoo-dev] USE database?
  2001-12-07 21:39             ` Daniel Robbins
  2001-12-07 21:43               ` Geert Bevin
@ 2001-12-08  1:44               ` Mikael Hallendal
  1 sibling, 0 replies; 26+ messages in thread
From: Mikael Hallendal @ 2001-12-08  1:44 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

fre 2001-12-07 klockan 22.39 skrev Daniel Robbins:
> On Fri, Dec 07, 2001 at 08:28:05PM +0100, Sebastian Werner wrote:
> 
> > Why not XML... it's really nice to edit i think
> 
> Because XML requires a whole new bloated, slow parser, and the python
> parser is fast and the syntax is lean and mean.  Also, if we port to
> C, it would be more effective to support "python-style" dictionary
> definitions that include and entire XML parser.  Also consider that
> XML has no equivalent of python dictionaries.

Actually parsing with libxml is really fast. But I agree, using XML in
these files makes no sense. It will make our basesystem depend on
libxml2 which I don't think it should.

Regards,
  Mikael Hallendal

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2001-12-08  1:44 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-12-03  1:06 [gentoo-dev] USE database? Zach Forrest
2001-12-03  7:41 ` AW: " Sebastian Werner
2001-12-03  9:13   ` Geert Bevin
2001-12-03 10:02     ` AW: " Sebastian Werner
2001-12-03 10:12       ` Geert Bevin
2001-12-03 11:05         ` AW: " Sebastian Werner
2001-12-03 11:05           ` Geert Bevin
2001-12-03 11:26             ` AW: " Sebastian Werner
2001-12-03 11:32   ` [gentoo-dev] New ideas, USE database, sandbox & more Vitaly Kushneriuk
2001-12-03 11:48     ` Geert Bevin
2001-12-03 12:55       ` Vitaly Kushneriuk
2001-12-03 14:01     ` Joshua Pierre
2001-12-03 16:06       ` Vitaly Kushneriuk
2001-12-03 16:28       ` Daniel Robbins
2001-12-03 18:00         ` Vitaly Kushneriuk
2001-12-03 16:48 ` [gentoo-dev] USE database? Daniel Robbins
2001-12-06  6:01   ` Mikael Hallendal
2001-12-06 18:12     ` Zach Forrest
2001-12-06 20:38       ` Mikael Hallendal
2001-12-06 22:33         ` Zach Forrest
2001-12-06 23:40           ` Daniel Robbins
2001-12-06 23:52             ` Zach Forrest
2001-12-07 19:28           ` Sebastian Werner
2001-12-07 21:39             ` Daniel Robbins
2001-12-07 21:43               ` Geert Bevin
2001-12-08  1:44               ` Mikael Hallendal

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox