[gentoo-dev] Interest Check: Dynamic config files for portage

[gentoo-dev] Interest Check: Dynamic config files for portage

[Seemant Kulleen]

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

Hi All,

Before I go and invalidate a bug, I thought I might take the idea around here to see if it has any merit in terms of usefulness/interest.

The idea stems from the fact that etc-updating a make.conf file can be a bit of a stressful event.  And as portage's set of features grows, so too will the size of the make.conf file.  I get the impression that the make.conf file is a little hard to parse, with the huge comment blocks etc etc.  So my proposal is this: a make.conf.d directory which contains files for each section of the make.conf: use, flags, fetch, packagevars.  That way, USE flags can be explained and specified in use, compiler flags in the flags file, fetch will contain the fetchcommands, mirrors (both distfiles and rsync), and packagevars can contain things like ALSA_CARDS for those of us on 2.4 kernels, and VIDEO_CARDS for those of us who have xfree/xfree-drm/whatever-future-windowing-system-we-add, and so on.  This way, the actual make.conf file (which tends to be about 10 lines of uncommented items in the usual case) can be dynamically generated from the information in those files.

Anyway, it's not an urgent issue by any means, but a thought.

Ciao,

-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://www.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E

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

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Ferris McCormick]

On Tue, 1 Jul 2003, Seemant Kulleen wrote:

> Hi All,
> 
> Before I go and invalidate a bug, I thought I might take the idea around here to see if it has any merit in terms of usefulness/interest.
> 
> The idea stems from the fact that etc-updating a make.conf file can be a bit of a stressful event.  And as portage's set of features grows, so too will the size of the make.conf file.  I get the impression that the make.conf file is a little hard to parse, with the huge comment blocks etc etc.  So my proposal is this: a make.conf.d directory which contains files for each section of the make.conf: use, flags, fetch, packagevars.  That way, USE flags can be explained and specified in use, compiler flags in the flags file, fetch will contain the fetchcommands, mirrors (both distfiles and rsync), and packagevars can contain things like ALSA_CARDS for those of us on 2.4 kernels, and VIDEO_CARDS for those of us who have xfree/xfree-drm/whatever-future-windowing-system-we-add, and so on.  This way, the actual make.conf file (which tends to be about 10 lines of uncommented items in the usual case) can be dynamically generated from the information in those files.
> 
> Anyway, it's not an urgent issue by any means, but a thought.
>
I like the idea.

 
> Ciao,
> 
> -- 
> Seemant Kulleen
> Developer and Project Co-ordinator,
> Gentoo Linux					http://www.gentoo.org/~seemant
> 
> Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
> Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E
> 
Regards,
--
Ferris McCormick (P44646, MI) <fmccor@inforead.com>
Phone: (703) 392-0303
Fax:   (703) 392-0401


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Rigo Ketelings]

Op di 01-07-2003, om 11:58 schreef Seemant Kulleen:
> Hi All,
> 
> Before I go and invalidate a bug, I thought I might take the idea around here to see if it has any merit in terms of usefulness/interest.
> 

Like the idea, not the name ;)....Is there anything against make.d ?

> The idea stems from the fact that etc-updating a make.conf file can be a bit of a stressful event.  And as portage's set of features grows, so too will the size of the make.conf file.  I get the impression that the make.conf file is a little hard to parse, with the huge comment blocks etc etc.  So my proposal is this: a make.conf.d directory which contains files for each section of the make.conf: use, flags, fetch, packagevars.  That way, USE flags can be explained and specified in use, compiler flags in the flags file, fetch will contain the fetchcommands, mirrors (both distfiles and rsync), and packagevars can contain things like ALSA_CARDS for those of us on 2.4 kernels, and VIDEO_CARDS for those of us who have xfree/xfree-drm/whatever-future-windowing-system-we-add, and so on.  This way, the actual make.conf file (which tends to be about 10 lines of uncommented items in the usual case) can be dynamically generated from the information in those files.
> 
> Anyway, it's not an urgent issue by any means, but a thought.
> 
> Ciao,

Rogi


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Interest Check: Dynamic config files for portage

[sf]

Seemant Kulleen wrote:
> Hi All,
> 
> Before I go and invalidate a bug, I thought I might take the idea around here to see if it has any merit in terms of usefulness/interest.
> 
> The idea stems from the fact that etc-updating a make.conf file can be a bit of a stressful event.  And as portage's set of features grows, so too will the size of the make.conf file.  I get the impression that the make.conf file is a little hard to parse, with the huge comment blocks etc etc.  So my proposal is this: a make.conf.d directory which contains files for each section of the make.conf: use, flags, fetch, packagevars.  That way, USE flags can be explained and specified in use, compiler flags in the flags file, fetch will contain the fetchcommands, mirrors (both distfiles and rsync), and packagevars can contain things like ALSA_CARDS for those of us on 2.4 kernels, and VIDEO_CARDS for those of us who have xfree/xfree-drm/whatever-future-windowing-system-we-add, and so on.  This way, the actual make.conf file (which tends to be about 10 lines of uncommented items in the usual case) can be dynamically generated from the information in those files.
> 
> Anyway, it's not an urgent issue by any means, but a thought.
> 
> Ciao,
> 

Why not leave make.conf alone and put the comments into make.globals?



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Georgi Georgiev]

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

On 01/07/2003 at 02:58:24(-0700), Seemant Kulleen used 1.8K just to say:
> The idea stems from the fact that etc-updating a make.conf file can be a bit
> of a stressful event. 

I used to feel the same way. Then I uncommented the 'diff_command="vim -d
%file1 %file2"' line in /etc/etc-update.conf and I stopped caring.

I, however, am not sure that distributing an /etc/make.conf is even necessary.
Put up an /etc/make.conf.sample instead of make.conf, like some packages do,
and let the user look at the sample file and set their own /etc/make.conf.

Which sounds very similar to what sf@b-i-t.de (sorry, no names, no signatures
there) commented - leave make.conf alone and put the comments in make.globals.
That should do the job.

-- 
\    Georgi Georgiev   \  GREAT MOMENTS IN AMERICAN HISTORY (#17): On  \
/     chutz@gg3.net    /  November 13, Felix Unger was asked to remove /
\   +81(90)6266-1163   \  himself from his place of residence.         \

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

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Lisa M.]

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

On Tue, 2003-07-01 at 05:58, Seemant Kulleen wrote:
> So my proposal is this: a make.conf.d directory which contains files for each section of the make.conf: use, flags, fetch, packagevars.  That way, USE flags can be explained and specified in use, compiler flags in the flags file, fetch will contain the fetchcommands, mirrors (both distfiles and rsync), and packagevars can contain things like ALSA_CARDS for those of us on 2.4 kernels, and VIDEO_CARDS for those of us who have xfree/xfree-drm/whatever-future-windowing-system-we-add, and so on.  This way, the actual make.conf file (which tends to be about 10 lines of uncommented items in the usual case) can be dynamically generated from the information in those files.

Sounds like a great idea.  No sense in parsing the whole make.conf when
you might not need anything (such as rsync vs. needing a whole bunch of
things).

-- 
Regards,
-Lisa
<Vix ulla tam iniqua pax, quin bello vel aequissimo sit potior>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Stewart Honsberger]

Seemant Kulleen wrote:

[..Quote trimmed Re: make.conf.d, line wrap seems absent..]

Sounds like a good idea to me, actually. make.conf is getting rather 
long winded and I only forsee it getting longer with every major Portage 
update, and like many others, I rue updating it, opting instead to 
manually add new directives and hope they're self-explanatory enough for 
down the road. :>

-- 
Stewart Honsberger
Gentoo Developer
http://www.snerk.org/


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Troy Dack]

Seemant Kulleen wrote:

>Hi All,
>
>Before I go and invalidate a bug, I thought I might take the idea around here to see if it has any merit in terms of usefulness/interest.
>
>The idea stems from the fact that etc-updating a make.conf file can be a bit of a stressful event.  And as portage's set of features grows, so too will the size of the make.conf file.  I get the impression that the make.conf file is a little hard to parse, with the huge comment blocks etc etc.  So my proposal is this: a make.conf.d directory which contains files for each section of the make.conf: use, flags, fetch, packagevars.  
>
Nice idea, something that I have thought about before.

The generated make.conf should have a *big fat* warning at the top 
specifying that it is a generated file and changes are to be made to the 
appropriate files in /etc/make.conf.d (or even just /etc/make.d).

Installation documents will have to be updated to specify the individual 
files to be editted.  Also utilities like ufed and the compiler flag 
generator will also need to be modified.

Suggested files in /etc/make.conf.d :
    use - use flags
    compiler - CFLAGS, CHOST, CXXFLAGS, MAKEOPTS
    distcc - DISTCC_HOSTS
    ccache - CCACHE_DIR, CCACHE_SIZE
    directories - PORTDIR, PORTDIR_OVERLAY, etc
    fetch - FETCHCOMMAND, SYNC,  GENTOO_MIRRORS
    advanced - FEATURES,  AUTOCLEAN

To those that suggest having a full make.conf.sample or add the comments 
to make.globals:
1. I can't say that I've read through make.globals, the install 
instructions say to avoid make.globals and edit make.conf (as does 
make.globals)
2. How many users read a sample file and then go and edit the real 
config? I generally copy the .sample to the .config and then edit it, 
with all comments in place.

-- 
    Troy Dack



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Lisa M.]

On Tue, 2003-07-01 at 09:41, Troy Dack wrote:
>     distcc - DISTCC_HOSTS
>     ccache - CCACHE_DIR, CCACHE_SIZE

These should be set with their own utilities (distcc-config and ccache).
Distcc, for one, should be using /etc/distcc/hosts or ~/.distcc/hosts to
determine what hosts to use - NOT the envvar $DISTCC_HOSTS. Especially
given Portage's propensity to change envvars, and users who may want to
use different hosts (~/.distcc/hosts) or none at all (localhost).

-- 
Regards,
-Lisa
<Vix ulla tam iniqua pax, quin bello vel aequissimo sit potior>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[William Kenworthy]

This is the reason that ufed has become so popular, and I think
necessary - the complexity is getting too much.  Would a ufed like
utility for make.conf be a better approach?  I am not so keen on
spawning a number of small bit files for a make.cond.d as that does not
fix the managebility issue - you will have to edit many files in turn,
instead of just one file every time.

BillK

On Tue, 2003-07-01 at 21:41, Troy Dack wrote:
> Seemant Kulleen wrote:
> 
> >Hi All,
> >
> >Before I go and invalidate a bug, I thought I might take the idea around here to see if it has any merit in terms of usefulness/interest.
> >
> >The idea stems from the fact that etc-updating a make.conf file can be a bit of a stressful event.  And as portage's set of features grows, so too will the size of the make.conf file.  I get the impression that the make.conf file is a little hard to parse, with the huge comment blocks etc etc.  So my proposal is this: a make.conf.d directory which contains files for each section of the make.conf: use, flags, fetch, packagevars.  
> >
> Nice idea, something that I have thought about before.
> 


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Alex Veber]

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

On Tuesday 01 July 2003 17:27, William Kenworthy wrote:
> This is the reason that ufed has become so popular, and I think
> necessary - the complexity is getting too much.  Would a ufed like
> utility for make.conf be a better approach?  I am not so keen on
> spawning a number of small bit files for a make.cond.d as that does not
> fix the managebility issue - you will have to edit many files in turn,
> instead of just one file every time.
>
> BillK
>
> On Tue, 2003-07-01 at 21:41, Troy Dack wrote:
> > Seemant Kulleen wrote:
> > >Hi All,
> > >
> > >Before I go and invalidate a bug, I thought I might take the idea around
> > > here to see if it has any merit in terms of usefulness/interest.
> > >
> > >The idea stems from the fact that etc-updating a make.conf file can be a
> > > bit of a stressful event.  And as portage's set of features grows, so
> > > too will the size of the make.conf file.  I get the impression that the
> > > make.conf file is a little hard to parse, with the huge comment blocks
> > > etc etc.  So my proposal is this: a make.conf.d directory which
> > > contains files for each section of the make.conf: use, flags, fetch,
> > > packagevars.
> >
> > Nice idea, something that I have thought about before.
>
> --
> gentoo-dev@gentoo.org mailing list

splitting make.conf to many files is not a solution.
imho we should create a tool to parse make.conf and change it.
that way we leave the choice to the user on how to modiffy his settings.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Aara0Q5UUdinJT4RAv86AKDawnH25KeJBNHTQc9kmA5kSM75AwCgzlS0
kCvCMlFYrwtsrS9Wkov6pC8=
=fCXa
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Troy Dack]

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

I'll state now that I like the idea of multiple files.

Bill K wrote thusly ...
> This is the reason that ufed has become so popular, and I think
> necessary - the complexity is getting too much.

For USE flags the complexity has increased, mainly because the number of
USE flags has grown and it's not possible to remember every single flag
and what effect it is going to have on building of packages.

> Would a ufed like utility for make.conf be a better approach?

I really don't like the idea of YAGU (Yet Another Gentoo Utility).  I
really like the fact that I can just edit the text files and I don't need
to start up a utility to do it.

The other reason I don't like YAGU is that someone will have to write it
and maintain it, this is not a trivial task as changes to portage will
eventually have some impact on how the utility is written and performs.

>  I am not so keen on
> spawning a number of small bit files for a make.cond.d as that does not
> fix the managebility issue - you will have to edit many files in turn,
> instead of just one file every time.

OK, about the only time that you will have to edit many files in turn is
during the initial installation process.  Personally I don't think that
this is a bad thing, if the documentation is accurate then the
installation process (editing the files) is an excellent educational
experience for new users.

This issue was initially raised due to the fact that a small change to
/etc/make.conf and then merging those changes using etc-update gets very
tiresome.  Generally the changes are simply to the comments and the
comments of only one section.  By having multiple files then only one file
(section) will be touched and you don't have to worry about the other 250
lines. [not having looked but could/can the "Merging trivial updates..."
stage of etc-update handle merging these comments?]

- --
     Troy Dack

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/AgpU/YkW+U2QvjwRAmiNAJwPx5STl3I8TW64n7tKHUpjeZv5SACgjg75
DtaaavUwXgeEfcgne01gaBA=
=IHun
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Georgi Georgiev]

On 01/07/2003 at 23:41:25(+1000), Troy Dack used 1.8K just to say:
> 2. How many users read a sample file and then go and edit the real 
> config? I generally copy the .sample to the .config and then edit it, 
> with all comments in place.

There is nothing bad with that either, is there? The point is that if there is
no make.conf in the distribution, there would be nothing to update with
etc-update. You like the comments - you're very welcome to keep them. The
problem we were facing was that etc-update was becoming difficult to use on
make.conf.

-- 
 /   Georgi Georgiev    / The Angels want to wear my red shoes. -- E.   /
\     chutz@gg3.net    \  Costello                                     \
 /  +81(90)6266-1163    /                                               /

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Toby Dickenson]

On Tuesday 01 July 2003 10:58, Seemant Kulleen wrote:
> Hi All,
>
> Before I go and invalidate a bug, I thought I might take the idea around
> here to see if it has any merit in terms of usefulness/interest.
>
> The idea stems from the fact that etc-updating a make.conf file can be a
> bit of a stressful event.  And as portage's set of features grows, so too
> will the size of the make.conf file.  I get the impression that the
> make.conf file is a little hard to parse, with the huge comment blocks etc
> etc.  So my proposal is this: a make.conf.d directory which contains files
> for each section of the make.conf: use, flags, fetch, packagevars. 

Are there any other advantages to having an /etc/make.conf.d?.... I dont see 
any.

If the *only* advantage is to reduce the headache when using etc-update, then 
surely we should be looking for improvements to etc-update and sdiff, rather 
than changing the structure of one of our core configuration files.

(And Im not sure the proposed solution will help much anyway.... why should 
updating multiple files in /etc/make.conf.d be any easier than updating one 
monolithic /etc/make.conf?)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Josep Sanjuas]

On Tue, 1 Jul 2003 15:05:02 +0100
Toby Dickenson <tdickenson@devmail.geminidataloggers.co.uk> wrote:

> On Tuesday 01 July 2003 10:58, Seemant Kulleen wrote:
> > Hi All,
> >
> > Before I go and invalidate a bug, I thought I might take the idea around
> > here to see if it has any merit in terms of usefulness/interest.
> >
> > The idea stems from the fact that etc-updating a make.conf file can be a
> > bit of a stressful event.  And as portage's set of features grows, so too
> > will the size of the make.conf file.  I get the impression that the
> > make.conf file is a little hard to parse, with the huge comment blocks etc
> > etc.  So my proposal is this: a make.conf.d directory which contains files
> > for each section of the make.conf: use, flags, fetch, packagevars. 
> 
> Are there any other advantages to having an /etc/make.conf.d?.... I dont see 
> any.
> 
> If the *only* advantage is to reduce the headache when using etc-update, then 
> surely we should be looking for improvements to etc-update and sdiff, rather 
> than changing the structure of one of our core configuration files.
> 
> (And Im not sure the proposed solution will help much anyway.... why should 
> updating multiple files in /etc/make.conf.d be any easier than updating one 
> monolithic /etc/make.conf?)
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
> 

I think there could be more advantages. It would make make.conf faster to parse from scripts, and this might one day become a necessity as it continues to grow.  It'd also make portage easier to maintain, because for example, if I want to change the disftile or rsync mirrors then I can edit /etc/make.conf.f/fetch, or whatever its name would be, instead of finding the appropiate vars in the big make.conf. In the files, all flags could have their detailed descriptions, so that you wouldn't need to open another file eg a make.conf.help. After the update, then we could run something like /sbin/portage-update then have a make.conf with only necessary stuff in it.

Also, we might have one configuration tool per topic, which is good instead of having each conf tool to deal with the entire make.conf. (And maybe a big setup tool that could call all the more specific others.)



Josep Sanjuas

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Toby Dickenson]

On Tuesday 01 July 2003 16:49, Josep Sanjuas wrote:

> I think there could be more advantages.

they dont seem very compelling.....

> It would make make.conf faster to
> parse from scripts,

There isnt much to be saved.....

$ time bash /etc/make.conf

real    0m0.005s
user    0m0.000s
sys     0m0.000s

> It'd also make portage easier to maintain, because for
> example, if I want to change the disftile or rsync mirrors then I can edit
> /etc/make.conf.f/fetch, or whatever its name would be, instead of finding
> the appropiate vars in the big make.conf.

And editing a 250 line file is hard because......

> In the files, all flags could
> have their detailed descriptions, so that you wouldn't need to open another
> file eg a make.conf.help. 

I agree that splitting the documentation into make.conf.help would be a step 
backwards.



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Owen Gunden]

On Tue, Jul 01, 2003 at 05:32:56PM +0100, Toby Dickenson wrote:
> On Tuesday 01 July 2003 16:49, Josep Sanjuas wrote:
> 
> > I think there could be more advantages.
> 
> they dont seem very compelling.....

There is one compelling advantage that I believe was intended by the
original poster.  That is this: in the current situation, when I upgrade
baselayout I get a new make.conf which I have to merge by hand.  In my
experience this is definitely the hardest file in /etc to merge because of
its size and the amount of customization I've done to it.  If it were split
into separate files, it would be easier to see where the new stuff is.
Also, I would be familiar with the particular sections that I'd made
changes to, so I could simply copy the maintainers version of any files
that I know I haven't changed.

I may be a special case, though; I can't use etc-update because it has IMHO
a horrendous interface.  

I'm skeptical about a configuration tool to fix make.conf automatically,
because I've seen so many such things go wrong.  On the other hand, ufed is
indispensible, and if such a utility were as easy-to-use and
easy-to-know-what-it's-doing as ufed I would definitely consider using it.

Owen
searching his pockets for 2 pennies..

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Toby Dickenson]

On Tuesday 01 July 2003 23:29, Owen Gunden wrote:
> On Tue, Jul 01, 2003 at 05:32:56PM +0100, Toby Dickenson wrote:
> > On Tuesday 01 July 2003 16:49, Josep Sanjuas wrote:
> > > I think there could be more advantages.
> >
> > they dont seem very compelling.....
>
> There is one compelling advantage that I believe was intended by the
> original poster.  That is this: in the current situation, when I upgrade
> baselayout I get a new make.conf which I have to merge by hand. In my
> experience this is definitely the hardest file in /etc to merge because of
> its size and the amount of customization I've done to it.  If it were split
> into separate files, it would be easier to see where the new stuff is.
> Also, I would be familiar with the particular sections that I'd made
> changes to, so I could simply copy the maintainers version of any files
> that I know I haven't changed.

I am proposing that we can get the same advantages by creating a better merge 
tool. That is, a merge tool specifically designed for merging configuration 
files. (but definitely not a ufed-style file-specific tool)

I spent some time last night merging make.conf... I think the problem is that 
sdiff (the tool used by etc-update) is using the standard diff algorithm that 
minimises diff size. This leads to it selecting chunks of differences that 
often dont "look right" to the etc-update user. The chunks of differences are 
very different to what you would get if you asked a human to isolate the 
differences between the two files.

I think the merging task would be much easier with a tool that found more 
useful chunks of differences. Perhaps something using Python's difflib 
module? Any feedback gratefully accepted.

difflib can be found in cvs here. Check out the comment that starts 
"SequenceMatcher is a flexible class for comparing...."
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Lib/difflib.py?rev=1




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Georgi Georgiev]

On 01/07/2003 at 17:49:23(+0200), Josep Sanjuas used 2.2K just to say:
> It'd also make portage easier to maintain, because for example, if
> I want to change the disftile or rsync mirrors then I can edit
> /etc/make.conf.f/fetch, or whatever its name would be, instead of finding the
> appropiate vars in the big make.conf.

So you'd actually have to find the appropriate vars in *all* those files. I'd
definitely not look in a file named "fetch" (since rsyncing hardly has anything
to do with fetching, considering what "emerge --fetch" does) for the means to
set my rsync server which only proves my point - you (or I if all gentoo devs
think like you) would first look in the wrong file. So every time I want to
change a var, I'll have to think where it might be in all those files.
Personally, I find looking for text in *one* file much easier when compared to
grepping a directory and THEN editing a file (and then running the tool to
mangle my files or "cat * > ../make.conf" or whatever).

-- 
 /   Georgi Georgiev    / He who is flogged by fate and laughs the      /
\     chutz@gg3.net    \  louder is a masochist.                       \
 /  +81(90)6266-1163    /                                               /

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Dhruba Bandopadhyay]

Seemant Kulleen wrote:
> The idea stems from the fact that etc-updating a make.conf file can be a bit of a stressful event.
 > And as portage's set of features grows, so too will the size of the 
make.conf file.

I've always thought that /etc/make.conf should consist of env. variables 
only, have no comments and be generated dynamically not from other 
smaller files but from a utility or tool of some sort.  Currently, the 
size of the make.conf file is huge and doing the following gives the 
essential structure that I'm talking about.

grep -v '#' /etc/make.conf | cat -s > ~/make.conf.basic; more 
~/make.conf.basic

You'll see that this is much more readable and easily editable. 
Comments can be placed in a different file such as /etc/make.conf.help. 
  However, given that this method also results in more than one file it 
also brings about the need for a directory.

I suggest /etc/portage/.  There is already a dir structure for 
/etc/portage/package.unmask.  As a result, it would make sense for all 
portage/gentoo related files to be placed in there.  This would include 
make.conf, rc.conf, help files and any others.

To summarise, directory structure: yes, dynamic: yes, from zillions of 
smaller files: no (that's backward progress).

A few of my thoughts.

With regards.
-- 
Dhruba Bandopadhyay | dhruba[AT]codewordt.co.uk | ICQ: 31628525
Gentoo-sources-2.4.20-r5 | XFree-4.3.0-r3 | Nvidia-1.0.4363 | 
E-0.16.6-pre4 | ~x86
D8250 | Intel P4 I850E | Nvidia GeForce4 MX420 | Turtle Beach Santa Cruz


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Svyatogor]

On Tue, 01 Jul 2003 15:12:20 +0100
Dhruba Bandopadhyay <dhruba@codewordt.co.uk> wrote:

> Seemant Kulleen wrote:
> > The idea stems from the fact that etc-updating a make.conf file can be a bit
> > of a stressful event.
>  > And as portage's set of features grows, so too will the size of the 
>  > make.conf file.

> I suggest /etc/portage/.  There is already a dir structure for 
> /etc/portage/package.unmask.  As a result, it would make sense for all 
> portage/gentoo related files to be placed in there.  This would include 
> make.conf, rc.conf, help files and any others.
> 
> To summarise, directory structure: yes, dynamic: yes, from zillions of 
> smaller files: no (that's backward progress).
> 
> A few of my thoughts.
> 
I don't actually see how rc.conf comes into game? I don't know about you but my
rc.conf has 7 vars set, like font for the console, display manager etc. Nothing
to do with portage at all.

However I agree with you that generating it from millions of small file is not 
a sollution of a problem. What would be much better is to have a utility for
that. It has been discussed here about two weeks ago. The idea was to have a
tool to set all gentoo-specific vars, including ones in make.conf IMHO that's
quite a good solution.


-- 
Sergey Kuleshov <svyatogor@gentoo.org>
Let the Force be with us!

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Svyatogor]

On Tue, 1 Jul 2003 02:58:24 -0700
Seemant Kulleen <seemant@gentoo.org> wrote:

> Hi All,
> 
> Before I go and invalidate a bug, I thought I might take the idea around here
> to see if it has any merit in terms of usefulness/interest.
> 
> The idea stems from the fact that etc-updating a make.conf file can be a bit
> of a stressful event.  And as portage's set of features grows, so too will the
> size of the make.conf file.  I get the impression that the make.conf file is a
> little hard to parse, with the huge comment blocks etc etc.  So my proposal is
> this: a make.conf.d directory which contains files for each section of the
> make.conf: use, flags, fetch, packagevars.  That way, USE flags can be
> explained and specified in use, compiler flags in the flags file, fetch will
> contain the fetchcommands, mirrors (both distfiles and rsync), and packagevars
> can contain things like ALSA_CARDS for those of us on 2.4 kernels, and
> VIDEO_CARDS for those of us who have
> xfree/xfree-drm/whatever-future-windowing-system-we-add, and so on.  This way,
> the actual make.conf file (which tends to be about 10 lines of uncommented
> items in the usual case) can be dynamically generated from the information in
> those files.
> 

Nice idea. Why not? It should make the make.conf easier to manage and easier to
update.

-- 
Sergey Kuleshov <svyatogor@gentoo.org>
Let the Force be with us!

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Robert Bragg]

Hello,

Too me, it sounds like your method of merging changes might be the problem. 
I haven't noticed a problem myself. I use etc-update with vimdiff.
vimdiff folds all common text between files and so all I have to look at
are the new changes (make.conf doesn't seem any worse than many other config
files in this respect) if I decide to update the _whole_ file then I
quite vimdiff and tell etc-update I want the old replaced, if I only
want _some_ of the new changes then I take what I like from the new
config file and edit my original config. Then when I quit vimdiff I can then
tell etc-update to discard the update.

That seems easy, I particularly like seeing any changes to the make.conf
file just so that no new gentoo features slip by unnoticed (which could
happen with the proposed seperate file setup, because I also like to
have comments autmerged on unedited files)

Rob

On Tue, Jul 01, 2003 at 02:58:24AM -0700, Seemant Kulleen wrote:
> Hi All,
> 
> Before I go and invalidate a bug, I thought I might take the idea around here to see if it has any merit in terms of usefulness/interest.
> 
> The idea stems from the fact that etc-updating a make.conf file can be a bit of a stressful event.  And as portage's set of features grows, so too will the size of the make.conf file.  I get the impression that the make.conf file is a little hard to parse, with the huge comment blocks etc etc.  So my proposal is this: a make.conf.d directory which contains files for each section of the make.conf: use, flags, fetch, packagevars.  That way, USE flags can be explained and specified in use, compiler flags in the flags file, fetch will contain the fetchcommands, mirrors (both distfiles and rsync), and packagevars can contain things like ALSA_CARDS for those of us on 2.4 kernels, and VIDEO_CARDS for those of us who have xfree/xfree-drm/whatever-future-windowing-system-we-add, and so on.  This way, the actual make.conf file (which tends to be about 10 lines of uncommented items in the usual case) can be dynamically generated from the information in those files.
> 
> Anyway, it's not an urgent issue by any means, but a thought.
> 
> Ciao,
> 
> -- 
> Seemant Kulleen
> Developer and Project Co-ordinator,
> Gentoo Linux					http://www.gentoo.org/~seemant
> 
> Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
> Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Aron Griffis]

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

Seemant,

For many of the reasons already mentioned, I don't like this idea.  I
don't understand the advantage over the current situation.

Seemant Kulleen wrote:[Tue Jul 01 2003, 05:58:24AM EDT]
> The idea stems from the fact that etc-updating a make.conf file can be
> a bit of a stressful event.  

I think it's more stressful with more files.  Furthermore, as somebody
already mentioned, this method allows new feature settings to be
installed without me knowing about it.  I'd rather just merge the large
file, see the new settings, etc.

> And as portage's set of features grows,
> so too will the size of the make.conf file.  

I don't see how this is a problem, or how splitting it up solves the
problem.

> I get the impression that
> the make.conf file is a little hard to parse, with the huge comment
> blocks etc etc.  

Again, multiple files just makes it harder.  Now I get to grep for the
setting I want to change before I can actually change it.

> This way, the actual make.conf file (which tends to be about 10 lines
> of uncommented items in the usual case) can be dynamically generated
> from the information in those files.

Somebody mentioned that it would be possible to consolidate the comments
to make.globals, and leave make.conf uncommented.  I think that would be
fine.  Alternatively, I'd just leave the situation as-is.

Aron

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

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Aron Griffis]

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

Seemant,

I'll follow up with one more thought...  The reason for the existence of
/etc/init.d, /etc/conf.d, /etc/env.d, /etc/cron.d, etc. is not to
arbitrarily split up configuration files into smaller sections.  It's
for a single reason: To allow the files to be installed by separate
packages.

Since /etc/make.conf is installed by a single package (portage, of
course), the logic used for the other /etc/*.d directories doesn't
apply.

Aron

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

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Grant Goodyear]

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

On Tue, 2003-07-01 at 22:56, Aron Griffis wrote:

> Somebody mentioned that it would be possible to consolidate the comments
> to make.globals, and leave make.conf uncommented.  I think that would be
> fine.  Alternatively, I'd just leave the situation as-is.

I'm fairly agnostic on whether or not make.conf should be broken into
pieces.  Personally, I'm quite happy w/ a single file, but I wouldn't
complain about a make.conf.d directory.

I do want to argue against moving the comments from make.conf to
make.globals, however.  Given the standard Gentoo policy that users
should never make changes to make.globals, I don't think it would make
sense for us to tell the same users: "Just look in make.globals to see
what you can do w/ make.conf".  I think that such a plan would lead to a
lot more users editing make.globals directly.

I also _like_ having the comments in make.conf.  As it is the first part
of portage that our users encounter, I think it behooves us to document
it as well as possible.  (That said, I do realize that we do have a very
nice make.conf man page, so the comments in /etc/make.conf are not
entirely necessary.)

Well past my bedtime,
g2boojum
-- 
Grant Goodyear <g2boojum@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Kumba]

Hmmm, Pondering this thread leads me to a few opinions of my own.  One, 
I have to sway away from splitting make.conf into multiple files.  I 
kinda like only having to tweak one file to alter the settings of the 
one system wide feature of Gentoo that makes it Gentoo -- Portage.

Breaking this up into multiple files I think would anger the user base. 
  Honestly, it's not that complex of a file.  And I rather like the 
large comment blocks that explain various features and settings of 
portage.  More information, the better, I always say.

Maybe if make.conf was in the format of a sendmail config file, 
something like this might be more warranted.  Users who don't want to 
have the comment blocks can simply delete them, and etc-update after 
merging a new portage takes very little time.  IMHO, I'd say this is 
extremely trivial right now.

On the other hand, perhaps some small changes could be made.  I do think 
the USE variable is just pointless.  There are *way* too many use flags, 
and setting these manually in make.conf is self-defeating.  Better to 
train people to make use of "ufed" to set the USE settings, and keep 
that file separate from make.conf, say /etc/env.d/useflags.

Other suggested changes are removing variables that affect tools outside 
portage, such as distcc and ccache.  They have their own userland tools 
to configure them.  At most, a comment block in make.conf, or more 
preferably, a note in the man page for these might be better.

Otherwise, I don't see much of a point to change the make.conf file.  I 
think it serves it's purpose well, and centralizes things nicely.  I 
think alot of the tools available for Gentoo outside of 'emerge' and 
'ebuild' should also be centralized in some form, like ufed, 
mirrorselect,  etc.., either by being merged into a single utility, or 
individually called from a central utility.

Just food for thought.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Owen Gunden]

On Thu, Jul 03, 2003 at 01:36:23AM -0400, Kumba wrote:
> On the other hand, perhaps some small changes could be made.  I do think 
> the USE variable is just pointless.  There are *way* too many use flags, 
> and setting these manually in make.conf is self-defeating.  Better to 
> train people to make use of "ufed" to set the USE settings, and keep 
> that file separate from make.conf, say /etc/env.d/useflags.

This reminds me--is ufed included on the installation CD yet?  When you
first build your system is the time when you most need to customize your
USE variables, but ufed is not available!  At least, it wasn't the last
time I installed (I believe I used rc 4).  When it gets included, it should
be made-note-of in the install docs as well.

Owen

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Spider]

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

begin  quote
On Tue, 1 Jul 2003 02:58:24 -0700
Seemant Kulleen <seemant@gentoo.org> wrote:

> Hi All,
> 
> Before I go and invalidate a bug, I thought I might take the idea
> around here to see if it has any merit in terms of
> usefulness/interest.
> 

O have to disagree/agree.
you can already do "source /some/other/place/useflags"   and declare
local USE flags there.. 
or, as I have mine structured:

GNOME="gnome esound gtk gtk2"
KDE="-kde -arts -qt" 
CRYPT="crypt ssl gpg ldap" 
USE="${GNOME} ${KDE} ${CRYPT} ipv6"


if you take care to re-define variables, and add a nice blank line
before, then etc-update won't barf on the config and think you changed
as much, meaning merge will be simpler.


So in this term, I'm against doing any modifications to the current
system, theres little need to do so, and to split configuration from
documentation is a bad thing in a configfile of this sort.


//Spider


-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

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

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Troy Dack]

Spider wrote:

>O have to disagree/agree.
>you can already do "source /some/other/place/useflags"   and declare
>local USE flags there.. 
>or, as I have mine structured:
>
>GNOME="gnome esound gtk gtk2"
>KDE="-kde -arts -qt" 
>CRYPT="crypt ssl gpg ldap" 
>USE="${GNOME} ${KDE} ${CRYPT} ipv6"
>  
>
Simple and yet so powerful, thanks Spider.

I seem to remember that there was a discussion on this some time ago 
.... I'll dig through my archives.

-- 
    Troy



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Interest Check: Dynamic config files for portage

[Devdas Bhagat]

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

On 01/07/03 02:58 -0700, Seemant Kulleen wrote:
> Hi All,
<insert bitching about wordwrap here>
> Before I go and invalidate a bug, I thought I might take the idea 
> around here to see if it has any merit in terms of usefulness/interest.
> 
> The idea stems from the fact that etc-updating a make.conf file can be a 
> bit of a stressful event.  And as portage's set of features grows, so 
> too will the size of the make.conf file.  I get the impression that the 
> make.conf file is a little hard to parse, with the huge comment blocks 
> etc etc.  So my proposal is this: a make.conf.d directory which contains 
> files for each section of the make.conf: use, flags, fetch, packagevars.
Instead of a make.conf.d or make.d, why not ship with a set of
sample-make.foo.conf files? The detailed comments can go in the sample
files, while the main make.conf has a few short comments.

I would suggest make.conf.global and make.conf.local. The global file
will summarily be overwritten by any upgrades, the make.conf.local file
will never be touched by it.

make.conf will include make.conf.global and make.conf.local
make.conf.local can have flags set in two ways:
append to flags in global:
	foo += flag flag flag
override global flags
	bar = flag flag flag
If there are two conflicting flags, the flags in .local take precedence,
with a warning logged to the user.

This should enable you not to have to bother about what has changed,
while allowing for local configuration specific customization.

<snip>

Devdas Bhagat

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