linux-pango/cairo vs firefox/seamonkey/flock

[Alexander Leidinger]

Quoting John E Hein <jhein at timing.com> (Sun, 2 Dec 2007 01:41:14 -0700):

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

Yes, but any package spec will not result in the same behavior than
what we have currently. You can specify a specific version, or a >=/<=
range. A specific version is to limited, and for <= you don't really
know the value to use as the upper limit.

> 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

You can add more than one dependency to the same port if you have to,
but typically the library version is bumped for all libs (yes, it's not
necessary, but that is what I observed for the ports which are
maintained by emulation@).

> dislike the hard-coded absolute pathname (for other unrelated
> reasons).

I agree for FreeBSD ports, but for _binary_ linux ports, absolute path
names relative to the base installation directory (in this case
LINUXBASE), is what is installed by the port we depend upon. We can not
really change this, as the dependency is a binary package and we can
not mix different prefixes (LINUXBASE) in the linuxulator. The
linuxulator is harder to handle than the rest of the system. If you
look at the non-linuxulator ports I maintain, you will see that I don't
depend upon specific libs, but hope that any lib version is ok (except
where I know that this is not the case). I prefer the relaxed way of
handling dependencies. But for the linuxulator infrastructure I went
more and more restricted after getting hit by pitfalls. I don't
remember all of them, but the current way the linuxulator
infrastructure is handled, is the result of them. There are cases where
this strict handling may not be ideal, but the alternative you propose
here is even less ideal than what we have currently IMO.

I don't object if you use this in ports which are not maintained by
emulation@ (if I see such use, I will tell my opinion about it, but the
maintainer is the one making the decision what is used), but for ports
maintained by emulation@, I claim some ownership (I invested a lot of
time to improve them), so I ask to follow the style you see in those
ports. If you want to change this, you have to come up with some hard
real world facts where it hurts. I'm open to change everything you can
come up with, if you can show it solves a real world problem without
impacting other cases.

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

The ports in question (let's call them gnome related ports) have a
history of coming with an overly verbose library name (currently:
libgtk-x11-2.0.so.0.600.10) and a link from a simple name to this
complex name. I expect that this stays this way. So if the simple link
doesn't fulfill our dependency needs anymore, we can switch to a more
specific link (yes, this is even more restricted than relaxed).

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

The way the things are currently done have a history. This history is
the result of several years of handling real world problems. With this
clamped down approach we get less problem reports than with the very
relaxed way of handling which was done before I laid my hands at the
linuxulator infrastructure ports.

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

The problem is, that we talk about edge cases. If we would change it,
we will not notice a problem for a while. For such minor updates like
for the ports in the subject, the proposed way of handling it will work
without problems. But as the person which did the linux_base-7 ->
linux_base-8 update and mentored the linux_base-8 -> linux_base-fc3 ->
linux_base-fc4 updates, I can tell you that major updates provide
enough pitfalls where this matters.

The previous updates went very nice, and as I know the complexity
involved there, I'm very happy about this. I would like to continue
with such smooth updates, and for this reason I suggest to follow the
existing style of dependency handling.

Bye,
Alexander.

-- 
ports/net/netcat port is useful not only for redirecting input/output
to TCP or UDP connections, but also for proxying them with inetd(8).
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137