depends rework thoughts.

[Steven Michalske]

the bitfield is for the default setting,

but to limit ourselfs to a default setting of what we expect is normal then 
its bad.  i rather see levels of defaultness.

that is where modes 2 4 8 and 16 come in to play

perhaps a bitfield isnt needed
but say levels
2 minimal
3 normal
4 nice extras
5 the bloat of all bloats

and then the user sets the level of bloat they want.
so if i set optional depends level 3  i would get a medium sized disrto
level 2 would be like im making a firewall
and level 4 would be like redhat/suse/mandrake
5 your nutz :-P
if an opt. depends was at level 2 any level higher in the settings would 
include it by default and the user wouldent be asked
only levels 1 or 0 would ask

the luser would only make a setting for the level in the lunar menu
and devlopers would set the optional depends default field/flag

the use of a bitfield was to allow the setting of options individualy and 
combined at the same time in one varible.  like a chmod 777  is really a 
bitfield all on.

lin would use defaults unless a -flag was given to say hey for this module I 
want you to use level blah

steve

On Tuesday 09 December 2003 2:22 am, ratler at lunar-linux.org wrote:
> Instead of using bitfields or maybe in combination with I would like to
> see an option to lin and lunar that will use a default setting for the
> optional depend without asking at all. I don't think setting bitfields for
> every optional depend is optimal, only bring in more confusion.
>
> Well that is my 2 cents.
>
> Sincerly
> Stefan Wold
>
> On Mon, 8 Dec 2003, Steven Michalske wrote:
> > missing info
> >
> > flags for optional depends will have a default status bitfield type
> > thingy.
> >
> > the bitfield will be something like this
> > levels of build
> >
> > unsupported = 0  (only fullSAconfig can see these ones)
> > ask_about_all = 1
> > minimal_no_ask = 2
> > normal_no_ask = 4
> > safe_extras_no_ask = 8
> > extream_bloat_no_ask = 16  AKA i want it all :-P
> >
> > add more? yea names need devlopment too
> >
> > in the lunar options menus you would set your choice modes and if you set
> > 2 - 16 youll wouldent be asked about any optional depends
> >
> > also for the new optional depends  the module and its info would be
> > passed as bash arrays of 5 elements
> >
> > optmod = ( modulename modeincludesflags --with --without "decstiption
> > stuff here" )
> > the space seperates the info
> > and to get the info
> > ${optmod[0]} through ${optmod[4]}
> > i believe this will work ans would allow bunches of one of many  optional
> > depends
> >
> > if and optional depends had multiple arrays passed to it then a list
> > would be given and a index asked for for which to include.
> > if in no_ask modes then if one is already installed, then the lowest
> > filled bit field module used, then first non exiled and so one
> >
> > theres some more food for thought
> > steve
> >
> > On Monday 08 December 2003 10:37 pm, Steven Michalske wrote:
> > > Hey team,
> > >
> > > With christmas break comming up i decided what my winter project will
> > > be.
> > >
> > > Start working on an improved depends system.
> > > I have talked about this with elaine mostly and now I want your
> > > opinions and thoughts on this matter.
> > >
> > > what that has come out of our dicussions is this.
> > >
> > > mode flags for the various types of depends
> > >
> > > normal : plain you must have this to work at all times
> > > optional : this can be selected as optional
> > > 	note optional depends will have a defaults flag.
> > > rebuild:  if the depender module is rebuilt then this module is rebuild
> > > 	example:  linux is a rebuild depends of pcmcia-cs
> > > run: this flag specified that this must be present to run the module
> > > but not to build the module
> > > build: this module is only needed in the build process
> > > 	e.g. something is required to to prase source code in a build step.
> > > one of many:  (needs a good name)  a list of modules that equate to the
> > > same
> > >
> > > these are combined thoughts as of yet  and the beginings of what is to
> > > come.
> > >
> > > steve
>
> _______________________________________________
> lunar-dev mailing list
> lunar-dev at lunar-linux.org
> http://dbguin.lunar-linux.org/mailman/listinfo/lunar-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 199 bytes
Desc: signature
Url : http://dbguin.lunar-linux.org/mailman/private/lunar-dev/attachments/20031209/4493799d/attachment.bin