Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 07 Aug 2007 11:15:09 +0200
From:      Alexander Leidinger <Alexander@Leidinger.net>
To:        Michael Nottebrock <lofi@freebsd.org>
Cc:        Kris, Henrik Brix Andersen <henrik@brixandersen.dk>, cvs-all@freebsd.org, ports-committers@freebsd.org, Pav Lucistnik <pav@freebsd.org>, Kennaway <kris@obsecurity.org>, cvs-ports@freebsd.org
Subject:   Re: cvs commit: ports/Mk bsd.port.mk
Message-ID:  <20070807111509.ojm8nc4ao0g080ck@webmail.leidinger.net>
In-Reply-To: <46B7072E.8070307@freebsd.org>
References:  <200706281553.l5SFr56i099807@repoman.freebsd.org> <20070802181715.46yikycm8gc8g8kk@webmail.leidinger.net> <20070803125410.GB1062@tirith.brixandersen.dk> <200708032144.57558.lofi@freebsd.org> <20070803204215.GA68620@rot26.obsecurity.org> <20070806074318.q9mw6ulngg00gwsw@webmail.leidinger.net> <20070806065634.GA31676@rot26.obsecurity.org> <20070806113855.0fcq213io0www04k@webmail.leidinger.net> <46B7072E.8070307@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Michael Nottebrock <lofi@freebsd.org> (from Mon, 06 Aug 2007 =20
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 =20
recursive dependency resolution. We just don't want to record the =20
implicit dependencies in the package or installed port. So =20
+REQUIRED_BY of the installed package/port will be different, and =20
@pkgdep in +CONTENTS will be different, but the end result (the =20
installed ports/packages) will be the same even if we would change the =20
default _now_ (this is not a suggestion to do this), except that =20
pkg_add would not moan about old installed packages if they are an =20
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 =20
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 =20
binaries (maybe with objdump, ldd is not really suitable for this task =20
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 =20
which are not catched by pointyhat will be reported by users. I =20
repeat, even switching now would not change the dependency tree or the =20
installed port/packages, just what is recorded in the package =20
(+CONTENTS) and in +REQUIRED_BY (in the depedencies). As this =20
information is not complete ATM, it would not be possible to get some =20
benefits from this ATM. So there would be some work required to get =20
most of the ports up to the new feature level, but it would not break =20
the current feature set of the ports collection.

I also think a lot of server ports already have all explicit =20
dependencies. The ports which require a lot of work are maybe =20
GNOME/KDE/..., so such a change would be a big impact for you (or =20
someone who is willing to track down) and the other maintainers of =20
those DEs (if you/they want to let users use this new feature for =20
those ports). As a maintainer you could decide to work as before =20
(which would maybe lead to some mails from sat@ or interested users =20
pointing out some missing dependencies ;-) ), or you can decide to =20
take care about the explicit dependencies (this can even be done step =20
by step). With an automation tool you would be able to catch some =20
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 =20
users help the maintainers by reporting missing stuff, than a short =20
term project where a lot of work has to be done by a small amount of =20
people (maybe a little bit of initial work if an exp-build shows some =20
differences... but ATM I can not come up with a scenario where a lot =20
of ports break when we enable this feature). I would also expect that =20
after one or two major updates of GNOME or KDE the explicit =20
dependencies are in a very good shape automatically.

Bye,
Alexander.

--=20
PLATONIC FRIENDSHIP:
=09What develops when two people get
=09tired of making love to each other.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID =3D B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID =3D 72077137



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070807111509.ojm8nc4ao0g080ck>