Bug 1224386 - Please package systemd-resolved seperate from systemd-network
Summary: Please package systemd-resolved seperate from systemd-network
Status: NEW
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: systemd maintainers
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-05-16 14:33 UTC by Richard Brown
Modified: 2024-06-04 08:23 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Brown 2024-05-16 14:33:14 UTC 
I get why resolved is packaged with networkd but there's also use cases where resolved would be very , very useful, even with NetworkManager

eg. I want it for openSUSE Aeon, with GNOME, with NetworkManager, but using resovled for more intelligent DNS resolution as people hop networks/VPNs.

Could we please package -resolved as it's own seperate thing and have it required by -networkd, as I really wouldn't like to have -networkd installed if I can avoid it.
Comment 1 Franck Bui 2024-06-04 07:40:43 UTC 
Just out of curiosity, why do you want to avoid it ?

As long as systemd-networkd remains disabled, it shouldn't cause any problems.

Is it only to spare a few Mo on the disk ?
Comment 2 Richard Brown 2024-06-04 07:50:04 UTC 
(In reply to Franck Bui from comment #1)
> Just out of curiosity, why do you want to avoid it ?
> 
> As long as systemd-networkd remains disabled, it shouldn't cause any
> problems.
> 
> Is it only to spare a few Mo on the disk ?

Aeon typically doesn't want extra binaries and services lying around on the disk that we're not using

There's always a chance my users will turn it on if its there

Then I'll have to deal with the bug reports

and I dont want that, as on Aeon we will only support NetworkManager
Comment 3 Franck Bui 2024-06-04 08:03:57 UTC 
(In reply to Richard Brown from comment #2)
> 
> Then I'll have to deal with the bug reports

Noted that you'll be the one who deal with systemd bugs on Aeon ;)

> and I dont want that, as on Aeon we will only support NetworkManager

Then it's easy to close such bugs as "not supported".
Comment 4 Richard Brown 2024-06-04 08:07:20 UTC 
(In reply to Franck Bui from comment #3)
> (In reply to Richard Brown from comment #2)
> > 
> > Then I'll have to deal with the bug reports
> 
> Noted that you'll be the one who deal with systemd bugs on Aeon ;)

I AM the one who deals first with ALL bugs on Aeon. I foolishly thought it was a good idea to make myself the default assignee for every category of that Aeon product.

You'll only ever get systemd-on-Aeon bugs from me if it's clearly outside of my realm of fixing..then I hand that over to you - like for example, this bug :)

> > and I dont want that, as on Aeon we will only support NetworkManager
> 
> Then it's easy to close such bugs as "not supported".

In a Tumbleweed-land where users are expected to mix & match what components are on their system, yes

But on Aeon there's an expectation that I ONLY ship stuff that I support. So if I'm shipping stuff that I don't support, that's weird.

And I'd rather avoid that..hence..this bug :)
Comment 5 Franck Bui 2024-06-04 08:23:45 UTC 
(In reply to Richard Brown from comment #4)
> You'll only ever get systemd-on-Aeon bugs from me if it's clearly outside of
> my realm of fixing..then I hand that over to you - like for example, this
> bug :)

Actually I would tend to think that this one belongs to the category of bugs you should be able to fix since it's purely something related to packaging ;)

Splitting packages has always been tricky to get it correctly done the first time, at least for me...