cvs commit: ports/Mk bsd.port.mk

[Alexander Leidinger]

Quoting Michael Nottebrock <lofi at freebsd.org> (from Mon, 06 Aug 2007  
13:34:06 +0200):

> 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  
implicit dependency.

> 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.

Bye,
Alexander.

-- 
PLATONIC FRIENDSHIP:
	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