On 5/24/06, Eddy Petrişor <eddy.petrisor@gmail.com> wrote:
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.
Attached is the patch as it is at the moment. Currently it is not tested, but wording suggestions/critics in templates are welcome. -- Regards, EddyP ============================================= "Imagination is more important than knowledge" A.Einstein
Attachment:
ppp-udeb_templates_and_logging.patch
Description: Binary data