Max Horn <[EMAIL PROTECTED]> wrote:

> At 13:57 Uhr -0400 20.04.2002, David R. Morrison wrote:
> >Max Horn wrote:
> >
> >>  Also we uncovered this problem with the conversion to shlibs: So far,
> >>  if you e.g. depend on audiofile, but already depend on FOO which
> >>  already depended on that, you could just drop the audiofile
> >>  dependency. But if now FOO is converted to BuildDepend on audiofile,
> >>  and depend on audiofile-shlibs - you know have a problem! Ugh.
> >>
> >>  This caught us in at least one case... We have to be careful...
> >>
> >
> >All the more reason to get this conversion done as soon as we can, IMHO.
> 
> Actually, no. All the more reason to change the way we did the 
> conversions so far!
> 
> >Otherwise we will have more and more packages which accidentally rely on
> >the old methods.
> 
> The problem is: when you change a package to use splitoffs, you can 
> potentially break many others packages! But it's not really the fault 
> of the maintainers of these packages, they all used to work fine!
> 
> Hence when something is changed to a splitoff, the one doing that 
> should be responsible to check all affected pacakges and fix them if 
> needed.
> 
> There is a nice tool to help: "apt-cache showpkg PACKAGE" will show 
> the reverse dependencies. Hence when one splitoffizes a package, one 
> should check all reverse dependencies (and I mean *all* i.e. follow 
> them thru), and check whether those potentially need an added 
> BuildDepends. The easiest way is to just always add the BuildDepends, 
> but of course it's more elegant to check whether it's actually needed.

OK, I agree we can do things this way.  I guess the place to start is with
packages which have already been divided, correct?

I think we have to leave it up to the maintainers of the other packages to
figure out whether it is safe to remove the BuildDepends.  The person
upgrading a package to splitoff type should just add the BuildDepends
wherever it *might* be needed. 

  -- Dave


_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to