On 17 Mar 2010, at 01:44, Daniel Macks wrote:
> On Tue, Mar 16, 2010 at 11:39:35AM +0100, Max Horn wrote:
>> [...]
>>
>> E.g. our old "gettext" package is not even marked obsolete, and if
>> I was looking for gettext, well, it would be the first thing for me
>> to see... :) Don't get me wron
On Tue, Mar 16, 2010 at 11:39:35AM +0100, Max Horn wrote:
> [...]
>
> E.g. our old "gettext" package is not even marked obsolete, and if I was
> looking for gettext, well, it would be the first thing for me to see... :)
> Don't get me wrong, I am not asking for it to be marked as such. I just w
On Tue, Mar 16, 2010 at 11:43:31AM +0100, Max Horn wrote:
> Am 15.03.2010 um 17:41 schrieb Daniel Macks:
> >>Max:
> >>
> >> The other alternative would be to implement the ancient idea of an
> >> "RuntimeDepends" (or "InstallDepends", or whatever) field. I.e. a field
> >> which is kind of the co
Am 15.03.2010 um 17:41 schrieb Daniel Macks:
[...]
>>
>> I am not sure what the best way is to resolve this, but I hope that it can
>> be resolved ... one idea that comes to mind is forbidding splitoffs to
>> depend on fink-obsolete-packages, i.e. enforcing a policy where either all
>> split
[...]
>>>
>>> And what does "when appropriate" mean?
>>
>> The package builds.
>
> And also that we aren't doing sweeps and making updates *just* for
> this issue (rev-up and force rebuild to migrate), but rather when
> updating packages for some other reason, "may as well also switch" at
> tha
Am 15.03.2010 um 23:58 schrieb Daniel Johnson:
>
> On Mar 15, 2010, at 12:53 PM, Daniel Johnson wrote:
>
>> On Mon, Mar 15, 2010 at 12:28 PM, Daniel Macks wrote:
>>> Two-level namespace *should* encapsulate things within each lib, but
>>> if one lib passes a struct or database to another, ther
