Date: Sun, 2 Dec 2007 01:41:14 -0700 From: John E Hein <jhein@timing.com> To: Alexander Leidinger <Alexander@leidinger.net> Cc: emulation@freebsd.org Subject: Re: linux-pango/cairo vs firefox/seamonkey/flock Message-ID: <18258.28586.544534.576946@gromit.timing.com> In-Reply-To: <20071201155115.5c6143a4@deskjail> References: <20071103210632.GB72327@amilo.cenkes.org> <1194124724.10479.35.camel@ikaros.oook.cz> <20071105204645.GE64094@amilo.cenkes.org> <20071116110040.247fnnkzk08gc0sc@webmail.leidinger.net> <20071130192912.GB1524@amilo.cenkes.org> <20071130210120.1c8b3150@deskjail> <18256.31317.682880.921587@gromit.timing.com> <20071201155115.5c6143a4@deskjail>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Leidinger wrote at 15:51 +0100 on Dec 1, 2007:
> Regarding the package-spec... the dependency is specific to a
> particular lib, the spec in the patch just says >=0. I'm a little bit
> uncomfortable regarding this. When we want to switch to a new linux
> base, we need to change most of the libs, and then the dependency
> doesn't match anymore (which means an overlooked ports is catched on
> pointyhat or on the tinderboxes). While we can add some text to
> UPDATING, I would like to have the dependency explicitly recorded in
> the port. Unlike the FreeBSD native ports, we have a more strict
> dependency regarding libs in the linux ports. I agree that the package
> spec will work for a lot of users, but with my experience with
> maintaining the linux ports and providing help for them since
> linux_base-8 I suggest to follow the practice we have currently in the
> linux infrastructure ports, as we can circumvent some pitfalls this way.
You don't have to specify a package >=0. It can be a specific
package rev. (yes, >=0 is probably a bit over-broad).
Specifying a specific file in that package as the RUN_DEPENDS key
(such as ${LINUXBASE}/usr/lib/libglib-2.0.so.0) is really just a
different way of doing things, and it doesn't capture dependencies
that are more than just that lib (for instance, what if a different
required lib that happens to be part of the same package changes, but
the one specified in the dependency remains the same?). I also
dislike the hard-coded absolute pathname (for other unrelated
reasons).
In one sense you can have finer control by specifying a package rev
than just one file in that package.
And with the advent of lib versioning, keying on a .so.N will not help
you if you want to capture the need for a new rev of a package, but N
doesn't change.
Those are just some "counterpoint" thoughts to look at things from a
different perspective. I would probably lean toward using the
"package spec" way of doing things and certainly not reject it just
because it's not the way things are currently done.
Maybe it'd be worth trying to use that way for a bit, at least for
this patch if not the rest of the linux ports, and see if it winds up
being better or not.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18258.28586.544534.576946>