cvs commit: ports/Mk bsd.port.mk

[Alexander Leidinger]

Quoting Kris Kennaway <kris at obsecurity.org> (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