Quoting Kris Kennaway <[EMAIL PROTECTED]> (from Mon, 6 Aug 2007
02:56:34 -0400):
On Mon, Aug 06, 2007 at 07:43:18AM +0200, Alexander Leidinger wrote:
>>Not sure this can work reliably enough to be usefule at present, at
>> least for
>>the specific scenario of avoiding unnecessary recompilations. I think
>>there
>>are just too many ports with implicit dependencies, especially in the
>>KDE/GNOME domain.
That's a bug in those ports IMHO. And that's the reason why this
feature is not enabled by default.
>Yes. I'm not even convinced this feature is a good idea.
"Not a good idea" as in "is not usable yet" or as in "it should never
be the goal to be usable"? If it is the former, I agree (see above).
If it is the later please elaborate (having correct dependency
information should always be a good idea, I think the benefits are
obvious, aren't they?).
Both: we're not there yet, and I don't see why this implementation is
the best way to get there :) Did I miss your discussion of the
proposal?
No, I thought it is obvious that a correct dependency information is a
"Good Thing"(tm).
- When you do sweeping changes or changes with a large impact (number
of ports), it is beneficial to have the real list of dependencies to
be able to know the correct dependency list. You don't want to waste
your time with ports which are listed as a implicit dependency but
are not really referenced in source/object files (the feature in
question is supposed to allow this). You also want to know about all
ports which depend directly upon it (this is where we are not ready
yet as not all ports list all explicit dependencies, an exp-build run
would tell about the critical ones, user reports after switching the
default would tell about edge-cases, some missing explicit
dependencies may perhaps not get reported at all if there's a strong
implicit relationship via an explicit dependency).
- Users which don't want packages but have to rebuild a lot of ports
(update of middleware ports) would not need as long to rebuild
the ports, as only the explicit dependencies need to be rebuild.
Imagine an update of libx11 which should be accompanied with an
update of everything which depends upon it. You don't really need
to rebuild all GNOME/KDE ports. In the current scheme one would
request a "portupgrade -rf libx11" or something to this effect and
it would rebuild a lot of ports which don't include any X11 includes
or link to X11 libs directly (you don't need to rebuild your
python or perl application which uses GNOME, you just need to update
gtk and some other middleware/critical ports).
- It may also motivate some people to work on some middleware ports
when they see that the explicit dependency list to a particular
port is relatively small (a huge number of ports which depend upon
a specific port may afraid people which would be willing to maintain
the port if there is a manageable amount of ports which depend upon
it).
I was tempted to say it also decreases the amount of time for
incremental package builds, but as the package dependencies change
(meta data for the portversion or portrevision) all packages which
have a changed port in their implicit dependency list will change and
have to be rebuild. So it doesn't cut down the official builds, but at
least the development und "user-update" time.
Those are the most prominent benefits, maybe there are some more in
the meta-info department (maybe portsmon can use some of this info,
...).
Regarding the negative aspects I can only come up with the opinion
that it makes it harder / is more work to create a port (it came up
some months/years before when explicit dependencies where discussed).
I question this opinion, as most of the time the dependencies are
listed somewhere for this software (readme/homepage/...). I also think
a good maintainer lists the explicit dependencies anyway (to not get
annoyed by pointyhat mails; and while you are at it, it is easier to
list all documented dependencies than to hunt down implicit
dependencies). Exceptions to this are very large "ports" like
GNOME/KDE (I take my hat off to the corresponding maintainers, you are
doing a great work in my opinion) where the dependency tree is huge
and the goal was to get it up and running completely (as of the
current way of registering implicit dependencies this is perfectly ok,
as it is not needed to do a cleanup of the dependency tree). But they
trade in work for the explicit dependency tree for testing work before
the next release of the mega-port to get a (more or less) smooth
update-experience for users. With an explicit dependency tree you can
let some automation tools like portupgrade/portmaster/exp-build/... do
the tedious work -> faster testing -> less total development time ->
faster turn-around time for updates.
Have I missed something? Kris, what technical reasons are against
explicit dependencies, in your opinion?
Bye,
Alexander.
--
Love is sentimental measles.
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
