We request assistance with maintaining the ifupdown package.

The package description is:
 This package provides the tools ifup and ifdown which may be used to
 configure (or, respectively, deconfigure) network interfaces based on
 interface definitions in the file /etc/network/interfaces.

The primary maintainer (josue) is essentially MIA, while the secondary maintainer (santiago) currently has no time to devote to the package's maintenance.

At the very least, outstanding bugs with patches need to be triaged, and the command options we pass to the new default DHCP client (dhcpcd-base) have to be tweaked on time for the Trixie release.

Martin-Éric

Hey Martin-Éric,

Thanks for open this RFH. It's something that we should have done sooner.

Well, I'm not MIA but I do understand where this come from, at least from
the ifupdown point of view. Sadly, I've been quite busy with $DAILY_JOB and
running low of Debian spoons just focusing on other packages, never having
the time or energy to get to ifupdown. I've been intending to remove my name
from the maintainers field for some time.
I've been leaning on santiago (Thanks you santiago!) on the ifupdown
maintainance but it looks like he hasn´t the time anymore.

I'll try to work on this over the weekend but I don´t promise anything,
if someone wants to step in please do!

Hi Martin, Santiago, Jose,

I'd be happy to adopt ifupdown as sole Maintainer with a very collaborative
mindset.

The way I see it the package needs strong technical direction due to the
enormity of the problem space it's trying to solve: Networking.

While the ifupdown code as-such isn't technically difficult. It being an
itegration point for a lot of tech generates friction that manifests as
outsized maintanance burdon relative to it's (LoC) size.

IMO switching to a team-maintanance model here *without* *first* doing the
work of *building* a strong team with a shared technical vision was a
strategic mistake that's just going to lead to infighting. We should revert
it.

I agree with Santiago, we should move towards ifupdown-ng, but I don't want
to do that until we have a really good understanding of the problem space
and whether ifupdown's model truly does solve enough of it to be useful in
the modern world.

Keeping traditional ifupdown alive will help me get some of that
understanding. The rest of it I plan to get by talking to people at NOG
groups, Linux, Debian, FLOSS and chaos events I'm actively attending. If we
don't understand our users we can't hope to solve their problems.

Taking over maintanance and (somewhat implicitly) Debian's default network
stack also aligns well with my plans of building a Debian based IPv6-only
focused routing appliance with public FLOSS funding. If that goes well I'll
have the necessary time and attention to devote to it's ongoing maintanance.

Perhaps most critically I'm planning on promoting it's use on the public
stage to convince more people that the fashionable monolithic designs of
today aren't the be-all-end-all they seem to think they are.

My brain can deal with bug reports going forward mostly fine, but I'm
terrible at processing existing piles of work. Alone anyway.

We should try to get together at DebCamp or another (virtual?) occation to
triage and chew through at least some of the bugs.

I've tried in the past and have frankly no idea how to even attack the pile
since BTS doesn't even let me sort reports by most recent activity to try
and prioritise by user interest/pain and it took me way to long to realise
I should probably sub to ifupdown in PTS (story of my Debian career ;D).

IMO we still have some patching work on dhcpcd to do to really make the
integration and upgrade story air tight, unless you have specific changes
in mind already that would take care of things?

Frankly as soon as I'm empowered to just make the necessary changes I'm
happy to do it. I have plenty of Debian events and time lined up before the
Soft Freeze still, but I don't want to do it if I have to fight over every
technical decision I make.

Good to know you're still around Josue :-).

Don't feel bad about it. Interest and motivation ebbs and flows.

IMO You shouldn't feel like you have to.

I'd just be happy for input on any particularly jucy/difficult bugs, maybe
major overall problems you think need addressing and the like.

Hello Daniel,

El 31/03/25 a las 18:31, Daniel Gröber escribió:

Maintainer is currently
Debian Networking Team <team+networking@tracker.debian.org>. It is not
clear to me if you are proposing to change that. Could you clarify it
please?
And just in case, I would prefer to keep it like that, and adding you as
Uploader.

Sure.

May I ask what do you propose to build a strong team?

OK

As far as it concerns me, join the current team, and you would be
empowered to make the changes.

+1

I haven't had the time to look at that. I believe Martin-Éric has a
better idea of priority bugs.

Cheers!

pe 4.4.2025 klo 4.25 Santiago Ruano Rincón (santiagorr@riseup.net) kirjoitti:

It was changed to team maintenance for a good reason. Let's not revert that.

I'd like to hear that too.

dhcpcd can already do most of what ifupdown does. The only serious
lacking it has is that it cannot handle hostap configs and it cannot
create bridges or vlans. Once that has been implemented, it could
replace ifupdown entirely.

TBH, many of the bugs that Daniel has filed against dhcpcd makes me
seriously ponder whether I'd trust him to make any change at all.

I have specific issues that have been left unattended to, some of
which specifically concern dhcpcd integration for Trixie. At the very
least, I'd like our CLI recipe to safeguard us against any upstream
change of mind for the default config. Another point would have been
to integrate bridge creation using 'ip' directly into 'ifupdown' and
retire bridge-utils, and also better document the fact that 'ifupdown'
can already create vlans without the old external package.

Martin-Éric