All developers plz read this!

[Nick Hudson]

Well obviously there are a few exceptions to the rule like Linux-PAM and
the kernel modules.  The way I see it is this, we need to stop all
dependancy asking of all the modules we can.  Personally I use Linux-PAM
on all my machines and when I 1st install it all it has to recompile is
maybe 4-5 modules.  Now the way it is now you will have to answer
question after question on those modules along with the question on the
Linux-PAM.  With the new way you would just answer "y" to rebuild all
PAM aware modules and it would compile away without asking another
question about the modules you are building for PAM.  Same will go for
the mozilla module.   The logic will be taken out (ie. the if
statements) and things will be installed by default.  We have to get rid
of all the questions for one they are annying as hell when you lin -c -r
a module you get asked the questions all over again for all deps even
though the deps are installed.  Anyway its a thought and I am going to
be working on the mozilla module today I guess just to see how it goes. 
But as csm said this is a must if we are to move foward to lunar2.

Nick


On Sun, 2003-08-24 at 11:53, Jeff Hodges wrote:
> On Sun, 2003-08-24 at 12:16, Chuck Mead wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > <csm> the DEPENDS in many of our modules are doing things that make it
> > difficult to impossible to move forward with lunar2
> > <csm> we have to stop doing logical code in the DEPENDS
> > <csm> so make it gtk2 and assume everyone wants everything... libical etc.
> > <csm> our "if" logic needs to come out of those DEPENDS files
> > <nhudson> ok np
> > <csm> and that means *ALL* DEPENDS need to be changed for this... no
> > logic in DEPENDS
> > <csm> in short it was a good idea which is unsupportable over the long haul
> > <nhudson> ok well I think that is the only module with logic in the
> > depends file but I will look over the moonbase and find out if there are
> > anymore like it
> > <csm> okay
> > <csm> anyplace we have it... "max_options" become defaults
> > <csm> if you see what I mean
> > <csm> if there is a way to do it in BUILD that's fine (maybe) but if you
> > think about it that may raise serious issues as well
> > <csm> there are many, many builds that may have to be re-written to make
> > the jump to lunar2
> > <nhudson> well frankliy I am tired of being asked do I want to install
> > this or that 400 times in a module
> > <nhudson> I would just rather have everything installed for it and be
> > done with the module
> > <csm> yes... and in fact the *RULE OF LAW* with virtually every other
> > AMS in existence is that it must run/install completely automagically
> > <csm> RH would have the head of any dev who did that on a silver platter
> > <csm> for instance... the nano install was recently reworked to ask
> > questions...
> > <csm> I say no questions but max options by default
> > <nhudson> yeah I agree, I dont care how many deps it has just install
> > them and be done with it
> > <nhudson> well I will get started on that this afternoon
> > <csm> okay... and glad you see my point
> 
> The only problem I see with this is the Linux-PAM based modules.  Myabe
> I'm missing something and if so please correct me but there are many who
> do not wish to use Linux-PAM and do not want to have to deal with the
> possible forced reinstallation of some modules.  I know there must be
> other options that can cause similarly annoying problems (or might be in
> the future) and as such, the forcing of certain questions are
> necessary.  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dbguin.lunar-linux.org/mailman/private/lunar-dev/attachments/20030824/52eec579/attachment.bin