Page MenuHomeFreeBSD

pkgbase: Put dhclient in its own package
ClosedPublic

Authored by manu on Aug 16 2022, 7:22 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 3, 7:14 AM
Unknown Object (File)
Sat, Oct 26, 6:15 AM
Unknown Object (File)
Sep 27 2024, 3:40 AM
Unknown Object (File)
Sep 22 2024, 11:40 PM
Unknown Object (File)
Sep 17 2024, 3:02 PM
Unknown Object (File)
Sep 9 2024, 6:12 AM
Unknown Object (File)
Sep 9 2024, 6:12 AM
Unknown Object (File)
Sep 4 2024, 4:34 PM

Details

Summary

It doesn't really make sense to have it in runtime and let's not
bloat utilities more.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 46964
Build 43853: arc lint + arc unit

Event Timeline

manu requested review of this revision.Aug 16 2022, 7:22 PM
emaste added a subscriber: emaste.
emaste added inline comments.
release/packages/Makefile.package
37

I wonder if we should call it "ISC-derived DHCP Client" or similar, to distinguish from possible upcoming dhcpcd?
D22012

The one we use is really OpenBSD's version of ISC dhclient, but they've since replaced it with a bespoke one so I wouldn't want to call it OpenBSD DHCP Client.

This revision is now accepted and ready to land.Aug 29 2022, 1:11 AM

This makes we wonder if the contents of /rescue should remain as a single rescue package... or if its contents should include files from other packages (like this dhclient package)?

This makes we wonder if the contents of /rescue should remain as a single rescue package...

That's a great question, we should move it to the mailing list

This makes we wonder if the contents of /rescue should remain as a single rescue package...

That's a great question, we should move it to the mailing list

How else would you package rescue? It's a single binary with lots of hard links. It makes no sense to
package it as anything other than a single package.

In D36222#826487, @imp wrote:

This makes we wonder if the contents of /rescue should remain as a single rescue package...

That's a great question, we should move it to the mailing list

How else would you package rescue? It's a single binary with lots of hard links. It makes no sense to
package it as anything other than a single package.

Yup.

In D36222#826487, @imp wrote:

How else would you package rescue? It's a single binary with lots of hard links. It makes no sense to
package it as anything other than a single package.

I’m thinking of the situation where I’ve decided I don’t want dhclient, so I remove the dhclient package (or never install it) but I do have the rescue package.

In that case would the /rescue/dhclient be a hard link to nowhere, or would it contain its own copy of the file?

In D36222#826487, @imp wrote:

How else would you package rescue? It's a single binary with lots of hard links. It makes no sense to
package it as anything other than a single package.

I’m thinking of the situation where I’ve decided I don’t want dhclient, so I remove the dhclient package (or never install it) but I do have the rescue package.

As long as we build dhclient by default (we don't have WITH_DHCLIENT or something like that right now) dhclient will always be part of rescue.

In that case would the /rescue/dhclient be a hard link to nowhere, or would it contain its own copy of the file?

All rescue binaries are crunched together with crunchgen in /rescue/rescue and then we create some hardlink for all the files that we crunched so without installing FreeBSD-dhclient you will still have a dhclient in /rescue.

In D36222#826487, @imp wrote:

How else would you package rescue? It's a single binary with lots of hard links. It makes no sense to
package it as anything other than a single package.

I’m thinking of the situation where I’ve decided I don’t want dhclient, so I remove the dhclient package (or never install it) but I do have the rescue package.

In that case would the /rescue/dhclient be a hard link to nowhere, or would it contain its own copy of the file?

It would be a hard link to the crunchgen'd rescue binary, just like the other 143 binaries that hard link to the rescue binary. This is
independent of what's installed on the base system: /rescue is designed to be self-contained and a little minimalistic so you can
use it to repair a system that's been otherwise damaged. While there's also a dhclient-script included with rescue so that
dhclient works, that too is independent of the rest of the system. Rescue by its nature is monolithic, and can't be subsetted
in any meaningful way with the current pkgbase setup.

In D36222#826605, @manu wrote:
In D36222#826487, @imp wrote:

How else would you package rescue? It's a single binary with lots of hard links. It makes no sense to
package it as anything other than a single package.

I’m thinking of the situation where I’ve decided I don’t want dhclient, so I remove the dhclient package (or never install it) but I do have the rescue package.

As long as we build dhclient by default (we don't have WITH_DHCLIENT or something like that right now) dhclient will always be part of rescue.

In that case would the /rescue/dhclient be a hard link to nowhere, or would it contain its own copy of the file?

All rescue binaries are crunched together with crunchgen in /rescue/rescue and then we create some hardlink for all the files that we crunched so without installing FreeBSD-dhclient you will still have a dhclient in /rescue.

Ahh.... it was my misunderstanding of how rescue worked that was the root cause of my question. I naively thought the contents of /rescue were hardlinks to the binaries in /bin/, /sbin, etc...

Now that I understand they are crunchgen'd together, it makes sense that /rescue/dhclient would remain part of the rescue pkg.

I learned something today - thanks guys.

This revision was automatically updated to reflect the committed changes.