[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [LONG] ppp-udeb: A succesful installation using it, some ideas and some requests for advices

On 5/19/06, Eddy Petrişor <eddy.petrisor@gmail.com> wrote:
On 5/16/06, Eddy Petrişor <eddy.petrisor@gmail.com> wrote:
> On 5/16/06, Marco d'Itri <md@linux.it> wrote:
> > On May 16, Eddy Petri??or <eddy.petrisor@gmail.com> wrote:
> > The case of "ethernet interface needs to be up without an IP address"
> > must be handled by the code which currently configures ethernet
> > interfaces (if you can persuade the maintainers).
> This is where I disagree, because I think there is no reason and no
> means for the previous steps to allow such a configuration (iirc,
> "leave network interface unconfigured" will just do that, no up, no
> IP), so I guess is the ppp-udeb's duty to do the up, if it needs it
> for PPPoE. Probably is not the best design, from your POV, but I don't
> think that the modular architecture of d-i will enforce this.

It is still unclear to me if an error should be displayed if the
ppp-udeb postinst will not detect _any_ concentrators, thus failing to
configure PPPoE. This should be always done if ppp-udeb is an opt-in
component (i.e. must be loaded as an additional component);

BUT if the ppp-udeb is integrated in the main d-i (better for
beginners who expect PPPoE to work out of the box), for many systems
there will not be a PPPoE connection, so what should be done in this
case? Silently fail? Frans, Marco?

Currently I have implemented loud errors based on the fact that
ppp-udeb is not integrated in D-I, but can be loaded on demand.

The patch is almost complete now and is missing just:
- a correct progressbar implementation (I _assumed_ that X seconds,
now X=10s, are enough to detect any concentrator); I would like to
have an implementation not based on such assumtions
- a way to remember the association between the used nic and the ppp
connection done over it; as the postinst starts a daemon, db_stop is
called at some point.

Is there a way to restore the dialog with debconf once db_stop has been called?

This would allow me to detect and store the nic:ppp_connection peer
which is used and dismantle it if the postinst is reran.

"Imagination is more important than knowledge" A.Einstein

Reply to: