Page MenuHomeFreeBSD

libutil++: Move to clibs
ClosedPublic

Authored by ivy on Wed, Aug 6, 11:00 AM.
Referenced Files
F127049985: D51756.diff
Wed, Aug 27, 12:04 AM
F127023850: D51756.diff
Tue, Aug 26, 4:57 PM
Unknown Object (File)
Fri, Aug 22, 9:28 PM
Unknown Object (File)
Thu, Aug 21, 7:23 PM
Unknown Object (File)
Thu, Aug 21, 6:58 PM
Unknown Object (File)
Tue, Aug 19, 7:56 PM
Unknown Object (File)
Tue, Aug 19, 9:30 AM
Unknown Object (File)
Mon, Aug 18, 11:39 PM
Subscribers

Details

Summary

This library only installs manual pages, so putting it in its own
package means we build a FreeBSD-libutil++-man package but not a
base FreeBSD-libutil++ package. Without a base package, the man
package can't be installed due to the missing dependency.

We don't really need a separate package for a few manpages, so move
it to clibs.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 66003
Build 62886: arc lint + arc unit

Event Timeline

ivy requested review of this revision.Wed, Aug 6, 11:00 AM

Not sure if clibs is the best package for this, maybe it fits better in runtime (which have libutil.so and the man in the -man) ?

it's a bit of an odd package since there's no reason to install it at all unless you're hacking on src, and i'm not sure we have any precedent for that. does it make sense to have a FreeBSD-src-man package? there are a few more things that we could perhaps move there, like src.conf(5). however, we'd need to make it not depend on FreeBSD-src.

In D51756#1182294, @ivy wrote:

it's a bit of an odd package since there's no reason to install it at all unless you're hacking on src, and i'm not sure we have any precedent for that. does it make sense to have a FreeBSD-src-man package? there are a few more things that we could perhaps move there, like src.conf(5). however, we'd need to make it not depend on FreeBSD-src.

I guess it might make sense if there is more than two manpages in it :)

I would probably place it beside libutil. It is true it is an INTERNALLIB, so it only has a static library (for the freebsd::stringf implementation) and not a shared library.

i'm really not sure runtime is the right place for this. libutil is only there because other things depend on it, but nothing can depend on libutil++ because it doesn't install anything (except manpages). but after thinking about it, clibs isn't the right place either, since it's not part of a C(++) runtime.

perhaps we should just dump it in -utilities like other miscellaneous libraries which don't have their own package?

des added a subscriber: des.

clibs is fine imo

This revision is now accepted and ready to land.Thu, Aug 7, 4:25 PM
This revision was automatically updated to reflect the committed changes.