[Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2

[Anssi Hannula]

On 05.01.2012 00:16, Michael Scherer wrote:
> Le mercredi 04 janvier 2012 à 20:09 +0200, Anssi Hannula a écrit :
>> On 04.01.2012 19:29, Michael Scherer wrote:
>>> Le mercredi 04 janvier 2012 à 16:16 +0200, Anssi Hannula a écrit :
>>>> On 04.01.2012 11:54, Michael Scherer wrote:
>>>>> Le mercredi 04 janvier 2012 à 11:03 +0200, Thomas Backlund a écrit :
>>>>>> Anssi Hannula skrev 3.1.2012 23:05:
>>>>>>> On 02.01.2012 12:21, guillomovitch wrote:
>>>>>>>> Name        : dsniff                       Relocations: (not relocatable)
>>>>>>>> Version     : 2.4                               Vendor: Mageia.Org
>>>>>>>> Release     : 0.b1.1.mga2                   Build Date: Mon Jan  2 11:18:17 2012
>>>>>>>> Install Date: (not installed)               Build Host: ecosse
>>>>>>>> Group       : Monitoring                    Source RPM: (none)
>>>>>>>> Size        : 210074                           License: BSD
>>>>>>>> Signature   : (none)
>>>>>>>> Packager    : guillomovitch<guillomovitch>
>>>>>>>> URL         : http://www.monkey.org/~dugsong/dsniff/
>>>>>>>> Summary     : Network audit tools
>>>>>>>> Description :
>>>>>>>> Tools to audit network and to demonstrate the insecurity of cleartext
>>>>>>>> network protocols. Please do not abuse this software.
>>>>>>>>
>>>>>>>> guillomovitch<guillomovitch>  2.4-0.b1.1.mga2:
>>>>>>>> + Revision: 189630
>>>>>>>> - drop epoch, we don't care about updating from mdv anymore
>>>>>>>
>>>>>>> We don't?
>>>>>>>
>>>>>>
>>>>>> Oh yes we do. Atleast from 2010.1
>>>>>
>>>>> We did for 1, not for 2 or cauldron or anything else. So as long the
>>>>> package is not pushed on 1, I think we agreed that people could not care
>>>>> about upgrade path from Mandriva.
>>>>
>>>> Well, I don't like that, IMO we should not remove upgradeability so
>>>> soon, even if we won't officially support it.
>>>
>>> Well, if we do not officially support it, then we do not support it,
>>> that's all. There is no "that's unofficially supported" or stuff like
>>> that. Supported mean "we will do test and fix bug if they happen", and
>>> not supported mean "we reserve our right to not do anything".
>>>
>>> And that's exactly what happen right now.
>>
>> IMO there is a level between "officially supported" and "we
>> intentionally break it", which means that we advise against it but do
>> not hinder people from doing it.
> 
> Yes, there is different levels of support, obviously, since people have
> different  but that doesn't mean we should rely on them, or try to
> officially use them. Again, saying "we support that, so we do that, and
> we don't support this, so people are free to do what they want" is
> simpler. 
> 
> The whole scheme of having "stuff we do", "stuff we do not promise but
> try to", "stuff we do not promise and we do not try to" ( or more ) make
> things less clear for everybody. Having a non uniform policy will make
> things harder for newer packagers ( and for olders too ). 
> 
> We have users ( in the past ) that complained about the lack of
> reliability of packages on Mandriva. And this was IMHO because we had a
> policy of 'we keep everything and we say they are in a section of "maybe
> supported"'. The whole message "contribs is not supported but main is"
> was simple and yet, too complex to grasp ( because people didn't check
> contrib/main before installing anything, )

It was not too complex, just badly implemented. The users got *no*
in-GUI notification at all that contrib was unsupported (most users
don't read wiki pages etc, especially if we don't link them to them).

> . It was also far from the
> truth because some stuff in contribs were more supported than stuff in
> main, and thus we were sending mixed messages. 

Right.

> So we should really stick on what we support, and send a simple, clear
> and correct message.
> 
> And I think we need to keep things simple to solve such issues in the
> long run.

I'm not advocating any change on the message sent to users, just to not
break upgrade intentionally (by removing near-zero-maintentance upgrade
support by dropping obsoletes/epochs that are needed for upgrade from
the several last distribution versions).

>>>> But anyway, this affects people doing 2010.1->mga1->mga2 as well... Or
>>>> are you saying that isn't supported either, and people should do new
>>>> installs??
>>>
>>> We do not support upgrading mdv2010.1 rpms with rpm from mga2, so if a
>>> maintainer want to remove this, he can.
>>>
>>> Someone doing mdv2010.1->mga1 will end with a mix of mdv2010.1 and mga1
>>> if the system is not cleaned, and that's not something we should
>>> support, not more than mga X + any random repository upgrade to mga X+1 
>>>
>>> IE, that's not mga1 -> mga2, that's mga1 + 3rd party repo that happened
>>> to work by chance to mga2. 
>>
>> I have to strongly disagree with this. If upgrading from 2010.1 to mga1
>> is officially supported (and it is), we can't say "you can't upgrade
>> your mga1 system to mga2 anymore because you have some old pkgs
>> installed which we never asked you to remove" (assuming no non-mdv 3rd
>> party repos here).
> 
> First,  it doesn't break the whole upgrade. 
> In fact, if we look carefully, people who were running non supported
> software ( ie a package from Mandriva ) will still run the same
> unsupported software and the same binary. And upgrade will likely work
> without error messages. Because nothing requires dsniff, except its own
> subpackage.
> 
> Secondly, it didn't matter much before Guillaume uploaded dsniff. 
> 
> 1 week ago, anyone who would have upgraded to mga2 with dsniff installed
> from mdv would have been in the exact same situation than now, except
> nobody cared at all. And the proof that nobody cared is that nobody
> pushed the rpm sooner. Would it have been pushed to 1, yes, that would
> have breached what we agreed to do. But it was not pushed to 1 ( and I
> would say "likely on purpose" ). So the only change with this upload is
> for people installing dsniff later.

I care. I also still have dozens of missing mdv packages in my TODO that
I intend to import to cauldron and mga1. dsniff was one of those, though
I'm not sure yet if I care enough about it to request it to submitted to
mga1 updates, since I don't use it on my mga1 systems (only on cauldron).

> 3rd point, the whole point of saying "we do not support this" is not to
> say "we don't support, but we should still support it to some extent".
> It is to be able to say "we do not support, so the maintainer can clean
> it if he want". You are free to support it if you wish, but Guillaume is
> also free to not support it, and choose to clean instead ( because epoch
> tags are ugly ). 

I completely agree. However, I consider this to break MGA1->MGA2
upgrade, which *is* supported.

> If we wanted to support upgrading from mdv 2010.1/2 to mga2, or
> upgrading people who mix distribution packages ( be it because they do
> not know, or on purpose, that's the same problem from a technical PoV ),
> it should have been said much sooner.

I'm fine with us not supporting 2010.1->mga2. However, I'm not fine with
breaking 2010.1->mga1->mga2.

And saying "it didn't completely break" while user has in his mga2
installation old packages is IMO not an option.

If it was intended that 2010.1->mga1 system wouldn't be completely
upgradable (all packages) to mga2, we should've made it clear when we
offered the mdv2010.1 -> mga1 upgrade path. But we didn't, so we should
completely support 2010.1->mga1->mga2 (with which I agree with).

> I do not understand, could people tell me what did they understood we
> would do when we said "we will not support upgrade this after mageia
> 1" ?

I understood it as 2010.1->mga2 would not necessarily work, but
2010.1->mga1->mga2 would still work fine, without old packages left,
except for those for which no new versions exist in the distribution.

-- 
Anssi Hannula