On Fri, Feb 25, 2022 at 10:31 AM Roy Marples <r...@marples.name> wrote:
>
> On 24/02/2022 21:31, Santiago R.R. wrote:
> >
> >
> > On February 24, 2022 10:21:38 PM GMT+01:00, "Santiago R.R."
> <santiag...@riseup.net> wrote:
> >>
> >>
> >> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine"
> <martin-eric.rac...@iki.fi> wrote:
> >>> Package: dhcpcd5
> >>> Followup-For: Bug #964947
> >>> X-Debbugs-Cc:
> sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org
> >>>
> > I have an NMU waiting on Mentors.
> >
> > <https://mentors.debian.net/debian/pool/main/d/dhcpcd5/dhcpcd5_9.4.1-0.1.dsc>
> >
> >> Thanks for your work! I do not have too much free cycles, but I will do my
> >> best to review and upload it soon.
> >
> >> After that, I will take a look at its integration with ifupdown.
>
> I will argue that integeration with ifupdown would not be a good thing, or at
> least not the sole integration.
>
> Since dhcpcd-5 it's been designed to run standalone monitoring interfaces as
> they arrive and depart and reacting accordingly.
> This operation is important on a multihomed system where wireless and wired
> for
> example could be assigned the same IP address.
The key idea with ifupdown is to be able to pass options to a variety
of network configuration tools via a centralized
/etc/network/interfaces configuration. Nothing more.
Right now, my personal experiements with dhcpcd indicate that
something as simple as passing options to wpa_supplicant via dhcpcd's
configuration file is not an easy task. Ditto for enabling prefix
delegation to a second interface. Via ifupdown's
/etc/network/interfaces these follow a normalized syntax that is
completely independant of which tools perform the actual network
configuration under the hood.
> > Configure's upstream default paths make Lintian bark, so I've kept the
> > overrides in debian/rules for now. It might be worth working with upstream
> > on making the defaults do what FHS and current packaging practices want.
>
> The default upstream paths mirror that of a BSD system. I belive that is in
> conflict with FHS.
There's more. For instance, manual pages canonically go to
/usr/share/man/manX (or /usr/local/share/man/manX for locally-built
packages). dhcpcd's Configure defaults put these in /share/man/manX if
no prefix is passed to configure. Also hooks are currectly put in
${prefix}/libexec (which is the correct FHS location), but since they
are not executable and lack the Bourne shell shebang, Lintian barks.
> > It's also worth noting that the maintainer and upstream both have
> > unpublished VCS commits on Salsa (most recent: Fri May 15 22:11:32 2020).
>
> My commits on Salsa are just me packaging dhcpcd.
> Looking, someone else decided to redo the NTP hooks entirely for Debian.
> My understanding is that the only thing the upstream hook doesn't do is
> timesyncd.
I wouldn't be surprised to find that Debian's own hooks are outdated
by now, except perhaps for timesyncd.
Martin-Éric
