-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Thanks so far for all the feedback and sugestions. I'll try to reply
to everyone in this mail.

One of the things most ppl ask is about what DB i'm using, why and if
i'm planning on support Mysql. I'm using PostgreSQL just because of
stored procedures that would allow easier notifications of machines
with vulnerable packages, etc. Also I had little experience with
postgresql and decided to give it a try. As far as mysql is
concerned, after I have a working version I will make sure the
project works with mysql too. For now, since I don't have much time
it will be only postgresql. The request for the database creation is
going to be filled, but unfortunately not until monday. I got the
umbrello diagram with me but i'm using a newer version at home, and
it's completely screwed up in umbrello 1.5. Will try to see if
there's a converter, if not on monday i'll mail it to the list.

About the longer docs, I have them all but in my native language,
Portuguese. If anyone understands portuguese I'll be happy to put
them online, for all the others i'm making new versions in English so
just wait some more time.

About CFengine, I took a look at it and will be taking some ideas,
but I don't expect to have a "econf" ready until the end of the
project, so it will be just to gather ideas.

> add the possibility to specify CFLAGS (or environment in general)
> for a single package or class of packages
 Excelent idea, haven't though of it yet. Thanks for bringing this up.

> keep possible to hook the function (pkg_setup, src_unpack ...)
 If I understood, you mean use this portage functions so we could add
some tasks specific to a networked portage. Another neat idea, but
outside the scope of the first release which must be done by the end
of January.

Also thanks for the links provided, will look into them during
weekend.

About econf, yes, I understand it's a hard terrain, but it just has
to be done, otherwise having to dig through configuration files in
each machine is a pain. Here's my initial idea:
- - econf would go through the old configuration file and detect
certain tokens and patterns described in the production rules.
- - it would then convert this tokens into the new file format (most of
the times they will not change)
- - Change the new file where changes in the old one existed.
This may be hard to get the picture, but let's see an example for
apache (httpd.conf). 
There are several kinds od tokens, the simple ones (PARAMETER value
(value1)) and the not_so_simple (<Keyword name>
PARAMETER ...</Keyword>). Now remember, the configuration file
included in the package (our new configuration file) would bring a
file listing all the tokens present in the new conf file. All we need
to do is go through the old file, identify the tokens and if they
match with the new one, replace their contents. Ok, now what if the
old file had very non-standard content? Warn the admin about this and
don't do a thing. If no exceptions arise, we backup the old
configuration file, replace with the new one and that's it, the admin
only need to make sure everything it's working. If not, roll-back and
see what went wrong. I think it's a good price to pay if most of the
time works fine. You could even make some test scripts to auto-test
the service, and if not working good, roll-back, but that's something
else.
The idea of marking which files econf should handle and which should
not is good, and will make sure the admin has freedom to specify
which files are taboo for econf.
But as I said before, I will only write about the idea, no code
should arise from this since my priority  is portagedb.

Sorry for the long mail, and thanks again for all the replies, they
were all very helpfull. Except new info by monday when i'm at the lab
again.

Ricardo Loureiro
- --
http://pgp.dei.uc.pt:11371/pks/lookup?op=get&search=0x6B7C0EC0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDmd4xJePPaWt8DsARAm/NAJ9zb9xZCeBOwQG2qOQF6b31KIXnpwCfXQl5
atQMBlybqgggrZysxiD5y0k=
=Sild
-----END PGP SIGNATURE-----

-- 
[email protected] mailing list

Reply via email to