Quoting Javier Fernández-Sanguino Peña (jfs@computer.org): > > 'semi up to date'. Still a lot of people use the outdated and utterly > > broken 1.8.4 release and complain. Although these complaints are correct, > Maybe because they are not aware of your backporting efforts. And they never will be, until they find one of the gazillion problems with 1.8.4 and report it. It's not the correct way, I agree. But i'm not going to fight release managers anymore to get snort 2.0.1 released in stable. > Yes, these utterly broken release is in all Debian CDs and mirrors. Bugs > are bugs, if they are not fixed then don't close them. BTW, they are not > even tagged properly (i.e. 'stable') The problem is that the buglist i'm having on snort now, consists of mainly bugs filed on the stable package of snort, which has been long solved in the later releases of snort that didn't make it in the release of Debian. It's annoying now, to see what bugs really are bugs, and what are bugs filed against stable. Some submitters didn't even specify versionnumbers. > > Before you object to this rather 'rude' bughandling, please keep in mind > > that version 1.8.4 of snort > Then you should work towards fixing them in stable or having ftp-masters > agreeing with including a new (backported) version at proposed-updates. We've been over this in debian-security before. I fixed the 1.8.4 package once, it got rejected, and I tried to have 2.0.x installed in Stable, but ofcourse, you can't put a new upstream version in a released stable Debian. That's why i'm doing backports on p.d.o, and that's why i want the bugs closed if I can't fix them. > > It's for the users best interrest that I tell them to use the new version. > It is for the best interest of the users that you provide a proper > snort version in proposed-updates. THEN LET ME! ffs! I know the way i'm going now isn't the correct way, but the tight rules about updating stable prevent me from doing it any better. Staying with 1.8.4 in Stable is useless, it is out dated, which is bad for a security tool. Going with 2.0.1 is impossible, because it might (and probably will...) introduce new bugs to stable. > This is a similar situation to #183524. We have to determine a way to > remove packages completely out of stable (due to unfixable security bugs, > for example) in a way that do not leave users exposed to these and their > bugs. A pseudo-package. But then what. Have people not run snort while using stable? I'm sorry if i sound harsh, i don't mean to. That's because of the rest of the replies in this thread. don't take it personal okay ;) Sander. -- | Waarom zit je achter een computer terwijl je er eigenlijk voor zit? | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D
Attachment:
pgpu9REgobqZ5.pgp
Description: PGP signature