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

Thu Jan 5 00:05:16 CET 2012

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
+