cvs commit: ports/Mk bsd.port.mk
Alexander at Leidinger.net
Tue Aug 7 09:17:35 UTC 2007
Quoting Michael Nottebrock <lofi at freebsd.org> (from Mon, 06 Aug 2007
> Alexander Leidinger schrieb:
>> Kris, what technical reasons are against explicit dependencies, in
>> your opinion?
Just to make sure we talk about the same: we don't want to disable the
recursive dependency resolution. We just don't want to record the
implicit dependencies in the package or installed port. So
+REQUIRED_BY of the installed package/port will be different, and
@pkgdep in +CONTENTS will be different, but the end result (the
installed ports/packages) will be the same even if we would change the
default _now_ (this is not a suggestion to do this), except that
pkg_add would not moan about old installed packages if they are an
> Explicit dependencies would be great, if they can be guaranteed to be
> correct, which basically means we need a way auto-generate them. Maybe
Auto generation would be nice, but it doesn't need to be a hard
requirement. See below.
> this could be done in a similar way to the security check target - run
> ldd/objdump over installed executables and libraries, record symbol
> names somewhere, determine dependencies by comparing records ...
I think this is a little bit over-engineered. Looking into the
binaries (maybe with objdump, ldd is not really suitable for this task
I think) for the references to libraries would be enough.
How do you want to calculate the RUN_DEPENDS?
> Explicit dependencies that need to be determined and maintained manually
> by port maintainers are useless, since they'll be almost guaranteed to
> be wrong most of the time for those ports that would profit the most
> (shave off the most implicit dependencies) from having them.
I don't think so. I think it will be the same as currently. Things
which are not catched by pointyhat will be reported by users. I
repeat, even switching now would not change the dependency tree or the
installed port/packages, just what is recorded in the package
(+CONTENTS) and in +REQUIRED_BY (in the depedencies). As this
information is not complete ATM, it would not be possible to get some
benefits from this ATM. So there would be some work required to get
most of the ports up to the new feature level, but it would not break
the current feature set of the ports collection.
I also think a lot of server ports already have all explicit
dependencies. The ports which require a lot of work are maybe
GNOME/KDE/..., so such a change would be a big impact for you (or
someone who is willing to track down) and the other maintainers of
those DEs (if you/they want to let users use this new feature for
those ports). As a maintainer you could decide to work as before
(which would maybe lead to some mails from sat@ or interested users
pointing out some missing dependencies ;-) ), or you can decide to
take care about the explicit dependencies (this can even be done step
by step). With an automation tool you would be able to catch some
LIB_DEPENDS very easy, so it would be not that much work for those.
Personally I see this more of a mid-term to long term project where
users help the maintainers by reporting missing stuff, than a short
term project where a lot of work has to be done by a small amount of
people (maybe a little bit of initial work if an exp-build shows some
differences... but ATM I can not come up with a scenario where a lot
of ports break when we enable this feature). I would also expect that
after one or two major updates of GNOME or KDE the explicit
dependencies are in a very good shape automatically.
What develops when two people get
tired of making love to each other.
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
More information about the cvs-ports