Re: about volatile.d.o/n
On Thu, Oct 14, 2004 at 03:37:57PM +0100, paddy wrote: What happens with a package orphaned from stable? As I understand it, the stable qa team manage it. Same should be with packages in v.d.o, since is part of the infrastructure of Debian (read WILL be, if agreed upon). I hadn't even stop to consider that a package might be orphaned in one archive but not another. Is there a specific scenario you're thinking of? A package in v.d.o which is orphaned should be taken over maintainership by another DD or qa. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Do us a favor...I know it's difficult for you...but please, stay here, and try not to do anything...stupid. --Jack Sparrow (Pirates of the Caribbean)
Re: about volatile.d.o/n
On Thu, Oct 14, 2004 at 04:29:37PM +0100, paddy wrote: Virus definition updates fit in the 'undesirable' category. Thats not to say some database can't be packaged. Here's a couple of references: [EMAIL PROTECTED] [EMAIL PROTECTED] (I'll post a reply with the ml archive web urls, in a hurry just now) Unless, of course I forget, can't find them or simply can't be bothered ;) http://lists.debian.org/debian-devel/2004/09/msg01272.html http://lists.debian.org/debian-devel/2004/10/msg00605.html Having tried to find these in the l.d.o web search interface, I now realise just how poor a form of reference they turn out to be. Apologies. Readers of the clam lists will be also be aware of stuff like: http://lists.clamav.net/lurker/message/20040813.111719.56a73be0.en.html as well other threads detailing the already significant distribution infrastructure of ClamAV, and looking for ways to make it faster. Regards, Paddy
Re: about volatile.d.o/n
paddy [EMAIL PROTECTED] writes: 'stable even for users who are misusing the system.' sounds like it could turn out to be a tall order, if it is intended to have wider application. It is a tall order. It is also one that Debian has done fairly well, by having very strict policies about stable. I think there need to be good reasons to depart from stable, and clearly, in some areas at least, there are. This may or may not be one of those areas, I don't see into it that deeply. I want to hear the *exact* reasons. So far, it has been things like: Virus scanners must be updated in order to remain useful. And so, we must be able to change locale information, add new command line args, or fix spelling errors in output sometimes. The first may be true. The second does not follow. I do not object to saying that some things must be updated to remain useful, and exempting them from the normal stable procedures. But we should not exempt the whole *package*, but specific *changes to the package*. Only those changes which must happen for the package to remain useful should be permitted. Other ones should not. Thomas
Re: about volatile.d.o/n
On Sun, Oct 17, 2004 at 11:33:49AM +0200, Andreas Barth wrote: * Martin Schulze ([EMAIL PROTECTED]) [041017 11:20]: Andreas Barth wrote: * Henning Makholm ([EMAIL PROTECTED]) [041011 18:30]: The goal should be that I, as a user, can add volatile to my sources.list and periodically do an apt-get upgrade - without risking to suddenly have my web browser updated to a new major release where it starts behaving differently, all my users' preferences get out of kilter, etc. I think this is one of the most important statements - and I think it describes our policy quite well. I could however see the possiblity to add a new package mozilla1.7, that users can optionally install. However, I also won't like it. Please be very careful with packages like these. It may require a new version of libfoo1 and libbar2g and libbaz0g etc. which people may accidently install, which in turn can hurt them in other areas and contribute strange bug reports. As soon as it requires new versions of some libraries, this is a no-go. People who want it may go to backports.org or so. Perhaps we may add an news item on volatiles page about that then. The main word is above all, do no harm. The default action is to not add something. Indeed, I think that major interests in volatile are about beta-quality software released in stable. A major upgrade would allow to use a 'sane' version which in turn should not require many library changes at all. I'm thinking to the pre-1.0 version of mozilla in woody: upgrading to a sane 1.0 version in stable by volatile could be considered, solving many functional problems and being a sane (and safe) possibility. Other major upgrades (e.g. mozilla-current) are backports.org concerns. We have currently a few software of large use in those conditions, e.g. firefox/thunderbird (but note that those programs are really in better conditions in respect with the old woody mozilla) -- Francesco P. Lovergine
Re: about volatile.d.o/n
On Sun, Oct 17, 2004 at 11:33:49AM +0200, Andreas Barth wrote: * Martin Schulze ([EMAIL PROTECTED]) [041017 11:20]: Andreas Barth wrote: I could however see the possiblity to add a new package mozilla1.7, that users can optionally install. However, I also won't like it. Please be very careful with packages like these. It may require a new version of libfoo1 and libbar2g and libbaz0g etc. which people may accidently install, which in turn can hurt them in other areas and contribute strange bug reports. Sometimes I could almost believe there is a libfoo :) As soon as it requires new versions of some libraries, this is a no-go. People who want it may go to backports.org or so. Perhaps we may add an news item on volatiles page about that then. Andi, I don't understand this. What is the harm (in new versions of libraries)? The main word is above all, do no harm. The default action is to not add something. Regards, Paddy
Re: about volatile.d.o/n
Thomas, On Sun, Oct 17, 2004 at 11:53:03PM -0700, Thomas Bushnell BSG wrote: paddy [EMAIL PROTECTED] writes: 'stable even for users who are misusing the system.' sounds like it could turn out to be a tall order, if it is intended to have wider application. It is a tall order. It is also one that Debian has done fairly well, by having very strict policies about stable. Indeed. Kudos to the many developers who work so hard to do this. Stable seems to achieve this by long timescales and restricting updates to a minimum. There will clearly be more pressure on such mechanisms for volatile. Perhaps it is possible, desirable and the will of the interested parties to pursue the same lofty standards, but that it is not as trivial as saying these same things should apply is, I feel, worth pointing out. After all it is the existing situation that leads us here today: these values can sometimes be at odds with other worthwhile values. Indeed, if you change these parameters, can you credibly claim to be applying the same standards? I think there need to be good reasons to depart from stable, and clearly, in some areas at least, there are. This may or may not be one of those areas, I don't see into it that deeply. I want to hear the *exact* reasons. So far, it has been things like: Virus scanners must be updated in order to remain useful. And so, we must be able to change locale information, add new command line args, or fix spelling errors in output sometimes. The first may be true. The second does not follow. Agreed. It doesn't necessarily follow. But that won't stop the policy cart being put in front of the purpose horse. WRT spelling errors, etc: The real case seems to me less trivial than the simplifications that have followed, but as a general rule I'd be happy to agree to not fixing spellings: as part of a _coherent_ policy going in the same direction, it makes perfect sense. I see no reason why, in principle, a volatile modelled on stable with just a shorter release cycle shouldn't be viable, and to some degree effective. I'm happy that there seems to be a rough concensus that volatile should have a purpose beyond a shorter release cycle, and that updates into volatile could be gated (in part) by consideration of their relevance to that purpose: that seems better to me. I imagine we're all a little curious or even nervous to find out what 'sufficiently relevant to purpose' will turn out to be. That really strikes me, it gets to the heart of things: the purpose of stable is ... the purpose of volatile is ... In the end we will have a good answer and all will be right in the world. Form will follow from function. It could easily be that blindly applying all of the expectations that people bring with them from stable could hobble volatile unduly, but I hope I'm just imagining that. But I'm floating away ... I can't yet see what puts new command line args in the same category as fixing spelling errors, except if that by the former you mean gratuitously incompatible changes to the command line interface, in which case we are in total agreement, but that is not clear given your previous phrasing: (IIRC) new command line features. But, it's a long way by the rules, but quicker by example, so ... Imagine a hypothetical virus scanner, let's call it foo. foo v.1 has no command line arguments in normal use: it takes stdin, it outputs on stdout/stderr. It scans for windows viruses only. Then, just suppose, foo takes on a capability to scan for a new Mac virus that is so resource intensive to scan for that the upstream wisely decide to make it an option: foo -m (in this particular case it could be argued that a separate name to call 'mfoo', might be better, but is that good answer to the generic problem?) Question: Can foo v.2 take its '-m' into volatile with it ? (I intend this as an example of a compatible command line change) I do not object to saying that some things must be updated to remain useful, and exempting them from the normal stable procedures. But we should not exempt the whole *package*, but specific *changes to the package*. Only those changes which must happen for the package to remain useful should be permitted. Other ones should not. I have considerable sympathy for what I perceive as your point of view, as I've said elsewhere. I'm still concerned that this area is considerably less black white than, for example, security fixes. Most likely individual maintainers will arrive at categorisations that in some way parallel those seen in security: remote hole, local hole, etc. and the whole thing will look less woolly. Perhaps some generalisation of these categories across volatile will be possible. No doubt, something like this already exists of which I am unaware. (I am not unaware of the grading of bugs for release management, I just can't see how it will play out). On a similar note, you seem to
Re: about volatile.d.o/n
Florian Weimer wrote: Can volatile receive critical updates which are usually not applied to stable because backports are not available for some reason? Are you speaking about mozilla? ;) Mozilla, GnuPG, and maybe even PHP 4, depending on sarge's lifetime. Other complex packages can easily enter this state, too, especially when sarge has been around for a year or two. Actually, Mozilla's situation is beginning to look rather promising. The distributor community seems to pick up the challenge and issue patches. Of course, if we release 1.6 with sarge (a version that is officially unsupported by upstream), we might not be able to profit from this development. This sounds more like a backports issue than anything that should go into volatile if the intention of volatile shouldn't be changed (and I hope it won't). Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. Please always Cc to me when replying to me on the lists.
Re: about volatile.d.o/n
Andreas Barth wrote: * Henning Makholm ([EMAIL PROTECTED]) [041011 18:30]: The goal should be that I, as a user, can add volatile to my sources.list and periodically do an apt-get upgrade - without risking to suddenly have my web browser updated to a new major release where it starts behaving differently, all my users' preferences get out of kilter, etc. I think this is one of the most important statements - and I think it describes our policy quite well. I could however see the possiblity to add a new package mozilla1.7, that users can optionally install. However, I also won't like it. Please be very careful with packages like these. It may require a new version of libfoo1 and libbar2g and libbaz0g etc. which people may accidently install, which in turn can hurt them in other areas and contribute strange bug reports. If you plan something like this, please at least use the componentised layout of backports.org and don't pollute the main volatile archive with this. (Still, I don't believe, such a packages incl. dependencies should go into volatile.debian.net.) Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. Please always Cc to me when replying to me on the lists.
Re: about volatile.d.o/n
* Martin Schulze ([EMAIL PROTECTED]) [041017 11:20]: Andreas Barth wrote: * Henning Makholm ([EMAIL PROTECTED]) [041011 18:30]: The goal should be that I, as a user, can add volatile to my sources.list and periodically do an apt-get upgrade - without risking to suddenly have my web browser updated to a new major release where it starts behaving differently, all my users' preferences get out of kilter, etc. I think this is one of the most important statements - and I think it describes our policy quite well. I could however see the possiblity to add a new package mozilla1.7, that users can optionally install. However, I also won't like it. Please be very careful with packages like these. It may require a new version of libfoo1 and libbar2g and libbaz0g etc. which people may accidently install, which in turn can hurt them in other areas and contribute strange bug reports. As soon as it requires new versions of some libraries, this is a no-go. People who want it may go to backports.org or so. Perhaps we may add an news item on volatiles page about that then. The main word is above all, do no harm. The default action is to not add something. If you plan something like this, please at least use the componentised layout of backports.org and don't pollute the main volatile archive with this. (Still, I don't believe, such a packages incl. dependencies should go into volatile.debian.net.) I'm definitly not adding a new package to volatile without being definitly sure that it should go in (and as long as you disagree, I'm not sure about that). And, as long as somebody thinks this polutes volatile, this also can't be the right thing. Volatile usage should be risk-free (as in security usage). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
On Thu, Oct 14, 2004 at 10:33:40AM -0700, Thomas Bushnell BSG wrote: paddy [EMAIL PROTECTED] writes: I can see your point of view here. Ironically, I've been assuming, purely on names, that you are more likely to be living in an english speaking country (as am I), whilst Sven might be less likely. More to the point, the issue isn't whether a well-behaved program uses only the C locale. It's that we should be stable even for users who are misusing the system. asbestos suit on They jabber away in that funny lingo of theirs, gawd bless'em, but we're all the same under the skin ain't we? /keep asbetsos suit on for few days just in case But I don't suppose that's what you meant :) 'stable even for users who are misusing the system.' sounds like it could turn out to be a tall order, if it is intended to have wider application. I think that in the end I come back to the obsevation that in the same way that we don't need 'just another backports', nor do we need 'just another stable'. What people suggest volatile might be seems to be about the score. If I summed together all the posts in these threads advocating features of stable for volatile, it seems an awfull lot like 'just another stable', but I don't see the point of being different just for the sake of it. I think there need to be good reasons to depart from stable, and clearly, in some areas at least, there are. This may or may not be one of those areas, I don't see into it that deeply. I can't help being struck by statements along the lines of 'we should be stable ...' I find I want to rewrite them 'we should be volatile ...' or, perhaps more sensibly, 'volatile should be stable' But, stangely enough, its the last one that bothers me the most. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
On Tue, Oct 12, 2004 at 09:44:30PM +0200, Sven Mueller wrote: paddy [u] wrote on 12/10/2004 18:14: If you put it that way, I have to agree with you. However, I would make one restriction: - packages in volatile have to keep their commandline (both input and output) interfaces compatible, would that be 'have to' as in 'MUST'? Yes. define compatible. Not really a good definition, but explains what I have in mind: If package A is updated, for it to still keep compatibility, the following needs to be fulfilled: Any pre-existing piece of software (let's call it X) which interfaces with A must stay fully functional. New features may be added to A and might not be available via the original interface, but any feature previously available must still work in the same way (less bugs being fixed). This also means that spelling mistakes in the C locale must be preserved (they may get fixed in other locales though, including en_US) as well as any (possibly even weird) output formatting. That last sentence also implies that any script using the commandline interface of A must reset LC_ALL and LANG to C or unset it. Otherwise the output format and wording might change from one revision to the other. This is good practise anyway, since you couldn't rely on a specific output formatting or wording without specifically setting a well-known locale. This sounds reasonable. I have yet to understand the value of 'no new command-lines interfaces' as opposed to 'no broken scripting interfaces'. Preserving specifically the system locale, seems like an excellent balance, and would go a long way to resolving the mailscanner example I gave (the output was to changed to give better functionality ...), I wasn't familiar with this convention, but it seems an excellent example of where a distro like debian can add value over upstream. I don't think 'less bugs being fixed' could stand without some qualification somewhere of what bugs it is acceptable to fix and cause breakage. but may change C/Python/Perl interfaces if no unresolved incompatibility in the whole of Debian is created that way. Yeah I've never liked those C/Python/Perl people either, not enough soldering irons! ;) grin It wasn't meant that way. But I think that locally written scripts shouldn't directly use the Perl module API (as in Mail::SpamAssassin for example) but use the commandline interface instead. I'm uncomfortable with the form of words, but with you on the intended destination. I think requiring absolutely static interfaces is too great a straight-jacket, but drawing a line like this, so that people know what to expect, is a good idea. The line seems drawn with the lay of the land to me. I imagine that the maintainers could shed much more light on this. However, as far as possible, what is the basis for the trade-off. You mean where I would draw the line for that? I would want to decide that case-by-case. If the change to the API is minimal and the work for avoiding it is tremendous (or other reasons make it important to incorporate that change), it seems wise to allow it in. they _should_ also keep those compatible. so that's just a bug then? ??? You mean the incompatibility? Suppose so. I wonder if a system where, in the event of breakage being deemed desirable, it is handled by a device like a package rename, for example spamassassin3, might be the way to go. I can imagine the hawks being concerned that this might provide a temptation to avoid the hard work of backporting, but it seems like a reasonable device to want to have in the armoury. Perhaps some safeguard could exist. For example the archive team could treat such a new package as they would a new candidate. If that were so then perhaps 'for C/Python/Perl incompatibilities the maintainer should consider (whatever that means!)' use of this device, whatever it is. As far as the trade-off goes, the example you give 'work for avoiding it' we also have 'critical to purpose', and I'm sure there are others. Not everyone will regard such purposes as equal, so, as with APIs, there may be some value in trying to enumerate them. There again perhaps a more realistic model is agent-centred: 'maintainer decides' I can't see the harm in pursuing both avenues at this stage. Returning to 'reasons to rename', perhaps a safeguard could be some consensus around what are reasonable trade-offs. Another reason for exception is an addition to the interface (as little interfering as possible) to allow scanning for and reporting of new security holes or viruses (for security/virus scanners). This is part of the definition of compatible? In a way, yes. see explanation above. The addition should interfere with existing interfaces as little as possible. If one wishes to make guarantees about APIs then it might be good to identify the APIs. It is surprising how much people's opinions can
Re: about volatile.d.o/n
On Wed, Oct 13, 2004 at 11:08:43PM +0200, Jesus Climent wrote: On Mon, Oct 11, 2004 at 02:32:01PM +0100, paddy wrote: Hmm, deja vu ;) What happens to packages that become orphaned? What happens with a package orphaned from stable? As I understand it, the stable qa team manage it. I hadn't even stop to consider that a package might be orphaned in one archive but not another. Is there a specific scenario you're thinking of? Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
On Tue, Oct 12, 2004 at 03:51:43PM -0700, Thomas Bushnell BSG wrote: Sven Mueller [EMAIL PROTECTED] writes: Any pre-existing piece of software (let's call it X) which interfaces with A must stay fully functional. New features may be added to A and might not be available via the original interface, but any feature previously available must still work in the same way (less bugs being fixed). This also means that spelling mistakes in the C locale must be preserved (they may get fixed in other locales though, including en_US) as well as any (possibly even weird) output formatting. That last sentence also implies that any script using the commandline interface of A must reset LC_ALL and LANG to C or unset it. Otherwise the output format and wording might change from one revision to the other. This is good practise anyway, since you couldn't rely on a specific output formatting or wording without specifically setting a well-known locale. No. It must behave identically, regardless of locale. Spelling fixes in the interface *cannot* be part of what the new version needs in order to remain useful. This is just the kind of dogde that has been worrying me about these proposals. Thomas I can see your point of view here. Ironically, I've been assuming, purely on names, that you are more likely to be living in an english speaking country (as am I), whilst Sven might be less likely. Do admins in non-english speaking countries use the C locale in this way? I like the C locale, it doesn't screw with the colation of my ls :) Clearly there is not absolute consensus on this convention. What sort of support does it enjoy? What (if any) equivalent policies already exist in debian? While there may be disagreement on the specifics, the value of proposals for exposing those disagreements and giving folk a chance to work things out seems good. I seem to recall that you originally encouraged proposals, and I would like to thank you for that. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
On Tue, Oct 12, 2004 at 10:26:34PM +0100, Henning Makholm wrote: Scripsit paddy [EMAIL PROTECTED] On Tue, Oct 12, 2004 at 03:05:05PM +0100, Henning Makholm wrote: But isn't volatile.d.o supposed to *be* the out-of-band mechanism (whatever out-of-band means here)? No. clamav virus signatures, for example, can be maintained by a program, freshclam, that downloads database updates from upstream. I know that, but as far as I under stande, the whole point of volatile is to replace exactly that with a situation where each maintainer does not have do program his own freshfoo system (and worry about finding a location to download from that is known in advance to stay availbale throughout the entire lifetime of the next stable release). We have different understandings. Some have expressed interest in using volatile in this way, and I don't see any objection to that, provided that it is a good way to solve the specific problem in hand. But, that is not 'the whole point of volatile', which is more as I describe (naturally :) I don't see how that means that there wouldn't be a need for rule updates. See above. The consensus seems to be that it would be undesirable to even try to push this data through the regular package-management channel. Whose consensus is this? The debian-devel feed that reaches me shows quite enthusiastic support for pushing rule updates through an aptable repository. Sorry, useless generalisation on my part: 'this data'. Let me try to be more specific. Virus definition updates fit in the 'undesirable' category. Thats not to say some database can't be packaged. Here's a couple of references: [EMAIL PROTECTED] [EMAIL PROTECTED] (I'll post a reply with the ml archive web urls, in a hurry just now) For things like snort and spamassasin, both approaches have value. For slower moving stuff, like the whois example, the question is more a case of 'what is a good way?'. And in any case the point is that I want to run a *stable* box. I am not keeping consciously track with upstream changes to background software like spam filters, so I didn't *know* that a 3.0 version was about to happen. A user of stable should be *able* to remain ignorant about such chages. Ah, but you weren't just a user of stable were you? You'd drunk from the forbidden waters of unstable! :) Because volatile does not currently exist. The point is to get improved *classification* without changing the *interfaces*. For me the point is to achieve function. Function may disappear totally if the update makes things break. Yes, different people, different software, different requirements. For me, a totally broken clamav is almost exactly as usefull as two-week out-of-date clamav, but that's because I believe that the system that I use can contain that breakage, so that I am _not_ talking about sending all the mail to /dev/null. If upgrading will break existing interfaces, then when means after the current testing freezes and is released as stable. Yes, for stable. Do we want 'just another stable' ? No, we want a way to push non-breaking data updates to stable users in a controlled way. They'll still be stable users, so they still want freedom from gratuitous breaking. A lot of these two threads has been dedicated to painstaking description of why 'data updates' doesn't cover it. If you s/mozilla/spamassassin/ I might want to argue the point. Well, I don't want to se an update to spamassassin in volatile if it breaks APIs that my scripts use. We are in broad agreement here. Please see discussion with Sven and Thomas elsewhere in this thread. Raising spam detection rates from 97% to 98% is useless if the update makes my mail system go catatonic and deliver all incoming mail, spam or not, to /dev/null. Agreed. I run stable on my mail server because I *don't* want random breakage, and if not having any random breakage means that I'll have do delete a bit more of my spam by hand, then so be it. Fine. If I wanted random breakage, I'd run testing on the server. But I don't. Makes perfect sense to me. And it all goes towards what you would like volatile to be. Why are we talking about mozilla? I don't know. You seem to have some kind of point about it, but I still cannot fathom what it is. I suspect its a hangover from earlier in the thread, and that neither of us is particularly interested in discussing that particular case. Given that, we'd do better to talk about what we do care about. That is my point. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
paddy [EMAIL PROTECTED] writes: I can see your point of view here. Ironically, I've been assuming, purely on names, that you are more likely to be living in an english speaking country (as am I), whilst Sven might be less likely. More to the point, the issue isn't whether a well-behaved program uses only the C locale. It's that we should be stable even for users who are misusing the system.
Re: about volatile.d.o/n
Daniel Burrows wrote: I generally have to resort to backports or unstable when installing Debian on recent hardware, because we don't update hardware drivers in stable. Would the kernel and X be candidates for volatile? Let me throw something else into the discussion here. With the new installer I expect we'll be able to produce significantly improves versions of the installer after sarge is released, that include things like kernel updates and other new features, and still support installing sarge (in addition to etch). The problem is that although they may install using a newer kernel, they have to get kernel packages to install from some apt repository. If that turns out to be volatile, so be it, if not we'll probably at least set up a backports style repository for such kernel images. -- see shy jo signature.asc Description: Digital signature
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 02:32:01PM +0100, paddy wrote: Hmm, deja vu ;) What happens to packages that become orphaned? What happens with a package orphaned from stable? -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 There's nothing that can't be done. --McManus (The usual suspects)
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 12:34:02PM -0500, John Hasler wrote: I see no reason for new packages to ever go into volatile. Such things belong in backports. You seem to have missed a very important ground of volatile: add new packages in a controled way when backporting code to the version in stable is far more difficult than guarantee a new version being stable enough to be updated. With all the policy added to it. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 I'm a mog: half man, half dog. I'm my own best friend! --Barf (Spaceballs)
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 07:22:15PM +0100, Henning Makholm wrote: To be fair, the issue is that if were just rules, there wouldn't be a need. Why not? I pretty much want to have the spamfilter rules on my mail box updated from time to time. Currently that has lead me to put a low-pinned unstable in sources.list and get spamassassin from there. But it was not meant to suddenly pull in spamassassin3. If volatile had existed, I could have avoided that. Read the thread. There are plenty of points you seems to be missing with your statement. J -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 London. You know... fish, chips, cup o' tea, bad food, worse weather, Mary-fucking-Poppins... London! --Avi (Snatch)
Re: about volatile.d.o/n
I wrote: I see no reason for new packages to ever go into volatile. Such things belong in backports. Jesus Climent writes: You seem to have missed a very important ground of volatile: add new packages in a controled way when backporting code to the version in stable is far more difficult than guarantee a new version being stable enough to be updated. New versions of packages already in Stable are not new packages. Clamav 1.0 would be a new version. BetterVirusGetter would be a new package. -- John Hasler
Re: about volatile.d.o/n
Scripsit Sven Mueller [EMAIL PROTECTED] Henning Makholm [u] wrote on 11/10/2004 20:22: [volatile.debian.org] Security fixes should be handled by security.d.o. Perhaps yes, perhaps no. Security fixes *to* packages already in volatile is a grey area, yes. I thought I was talking about security fixes to stable packages going in volatilie instead of security.d.o. -- Henning Makholm You want to know where my brain is, spetsnaz girl? Do you? Look behind you.
Re: about volatile.d.o/n
Scripsit paddy [EMAIL PROTECTED] On Mon, Oct 11, 2004 at 07:22:15PM +0100, Henning Makholm wrote: Scripsit paddy [EMAIL PROTECTED] To be fair, the issue is that if were just rules, there wouldn't be a need. Why not? Well, the argument goes: that can be done out-of-band, But isn't volatile.d.o supposed to *be* the out-of-band mechanism (whatever out-of-band means here)? but some updates involve changes or additions to the engine. There is a class of such software. I don't see how that means that there wouldn't be a need for rule updates. SA3 has been on the cards for some time now. Is there a policy around name changes at these times? could you have pinned (3.0) ? Not according to my understanding of apt pinning. And in any case the point is that I want to run a *stable* box. I am not keeping consciously track with upstream changes to background software like spam filters, so I didn't *know* that a 3.0 version was about to happen. A user of stable should be *able* to remain ignorant about such chages. That's what stable means. At the end of the day, I'm not certain exactly what you wanted protecting from, See the long thread about spamassassin3. The highlight is that the new version has a non-backwards-compatible API which makes certain other software stop working. I did not personally have any local scripts that depended on the old API, but I might have had. but it's hard to be certain that volatile would give it to you. After all the point is to get (at least some) changes. The point is to get improved *classification* without changing the *interfaces*. Clearly, but the *format* in which the virus scanner reports its findings should stay stable. You'll get no argument from me on the priciple of that. But what is stable? What if a format needs extending to take account of some new circumstance? Then a decision has to be made respecting the users' interest in having whatever local scripts they are using keep working. For instance, suppose there are Packages A and B in volatile. (A) has an interface (1) that is only used by (B) in the whole of debian. In the whole of Debian is not the only concern here; I would say it is not even relevant. Admins of un*x systems are *supposed* to write a truckload of local scripts to adapt their system to their wishes. That's the way it works. And our commitment in calling stable stable is that those local scripts will keep working across security updates, unless breaking them is necessary to close a hole. Similarly, if volatile is to be any value added over pinning unstable or testing, it must respect the same commitment. but the case for eventually upgrading to (1+) is compelling: it is only a question of when and how. If upgrading will break existing interfaces, then when means after the current testing freezes and is released as stable. You've said mozilla belongs in backports, which I'll take to mean: mozilla does not belong in volatile. I'm saying that *new upstream versions* of mozilla with hundreds of little interface changes, new preferences file formats, et cetera, does not belong in volatile. So you're not advocating mozilla in volatile. It may be that someone will come along that will advocate it in a compelling fashion, but I'm not holding my breath. Until then, if no one is building it, then what is there to knock down ? I do not understand that question either. Concrete example: I care about virus detection in the first two weeks, and even more so in the first few hours. To me not detecting a virus, purely because someone is correcting spellings would be downtime. (of course, if it's because _I'm_ too busy or too lazy, that's a different matter ! ;) I'm not sure what consequences this example has for what should and what should not be accepted in volatile. If the volunteer who would be preparing a rule update would rather use his time correcting spellings, we cannot force him. But that is probably not what you're getting at? -- Henning Makholm I tried whacking myself repeatedly with the cluebat. Unfortunately, it was not as effective as whacking someone else.
Re: about volatile.d.o/n
Henning Makholm [u] wrote on 12/10/2004 16:05: For instance, suppose there are Packages A and B in volatile. (A) has an interface (1) that is only used by (B) in the whole of debian. In the whole of Debian is not the only concern here; I would say it is not even relevant. Admins of un*x systems are *supposed* to write a truckload of local scripts to adapt their system to their wishes. That's the way it works. And our commitment in calling stable stable is that those local scripts will keep working across security updates, unless breaking them is necessary to close a hole. Similarly, if volatile is to be any value added over pinning unstable or testing, it must respect the same commitment. If you put it that way, I have to agree with you. However, I would make one restriction: - packages in volatile have to keep their commandline (both input and output) interfaces compatible, but may change C/Python/Perl interfaces if no unresolved incompatibility in the whole of Debian is created that way. However, as far as possible, they _should_ also keep those compatible. An exception can be made (like you said) if a change in interface is needed to close a security whole. Another reason for exception is an addition to the interface (as little interfering as possible) to allow scanning for and reporting of new security holes or viruses (for security/virus scanners). If upgrading will break existing interfaces, then when means after the current testing freezes and is released as stable. Like I said above, I generally agree. But I would only expect scripting interfaces in the meaning of commandline interfaces to remain compatible. If a sysadmin writes scripts which depend on an actual API, I think it is reasonable for him(/her) to track changes in the APIs (s)he is using and/or to mark the packages containing those APIs as hold. You've said mozilla belongs in backports, which I'll take to mean: mozilla does not belong in volatile. I'm saying that *new upstream versions* of mozilla with hundreds of little interface changes, new preferences file formats, et cetera, does not belong in volatile. OK, I would like to see it implemented approx. like this (names subject to change): - volatile.d.o: security and virus scanners, anti-spam software and similarly fast moving software needed mostly on servers - backports.d.o: New (versions of) user interface software (new KDE, new Mozilla and the like) Both might need security team support, which I would think is difficult for the later. cu, sven
Re: about volatile.d.o/n
On Tue, Oct 12, 2004 at 03:05:05PM +0100, Henning Makholm wrote: Scripsit paddy [EMAIL PROTECTED] On Mon, Oct 11, 2004 at 07:22:15PM +0100, Henning Makholm wrote: Scripsit paddy [EMAIL PROTECTED] To be fair, the issue is that if were just rules, there wouldn't be a need. Why not? Well, the argument goes: that can be done out-of-band, But isn't volatile.d.o supposed to *be* the out-of-band mechanism (whatever out-of-band means here)? No. clamav virus signatures, for example, can be maintained by a program, freshclam, that downloads database updates from upstream. These files do not come through the usual package management: you don't apt-get them. Similar situtations exist for other software with this kind of volatility. but some updates involve changes or additions to the engine. There is a class of such software. I don't see how that means that there wouldn't be a need for rule updates. See above. The consensus seems to be that it would be undesirable to even try to push this data through the regular package-management channel. SA3 has been on the cards for some time now. Is there a policy around name changes at these times? could you have pinned (3.0) ? Not according to my understanding of apt pinning. Pity, that would be a nice feature. And in any case the point is that I want to run a *stable* box. I am not keeping consciously track with upstream changes to background software like spam filters, so I didn't *know* that a 3.0 version was about to happen. A user of stable should be *able* to remain ignorant about such chages. Ah, but you weren't just a user of stable were you? You'd drunk from the forbidden waters of unstable! :) That's what stable means. I'd go along with that. I don't know what volatile will eventually mean. Clearly it can't mean exactly the same as stable, but it would be a shame if it couldn't provide a service in the I don't how it works, it just works class to users of stable. That isn't however my personal interest. At the end of the day, I'm not certain exactly what you wanted protecting from, See the long thread about spamassassin3. The highlight is that the new version has a non-backwards-compatible API which makes certain other software stop working. I'll go and do that, I had been skipping it ... I did not personally have any local scripts that depended on the old API, but I might have had. but it's hard to be certain that volatile would give it to you. After all the point is to get (at least some) changes. The point is to get improved *classification* without changing the *interfaces*. For me the point is to achieve function. Naturally one tries to avoid bugs and breakage. The standards of QA to which given software are important factors in the selection of that software. Volatile should have clear standards of QA so that users know what to expect, and mainatiners know what they are aiming for. I don't know how much of that it will be possible to write upfront, and how much will have to be learn along the way. Clearly, but the *format* in which the virus scanner reports its findings should stay stable. You'll get no argument from me on the priciple of that. But what is stable? What if a format needs extending to take account of some new circumstance? Then a decision has to be made respecting the users' interest in having whatever local scripts they are using keep working. Sounds reasonable to me. For instance, suppose there are Packages A and B in volatile. (A) has an interface (1) that is only used by (B) in the whole of debian. In the whole of Debian is not the only concern here; Agreed, and I did attend to the question of user scripts further down. I would say it is not even relevant. I think it could prove to be a consideration. Admins of un*x systems are *supposed* to write a truckload of local scripts to adapt their system to their wishes. I only use a soldering iron. scripts are for wimps. invoking trucks doesn't make them any less wimpy. ;) That's the way it works. And our commitment in calling stable stable is that those local scripts will keep working across security updates, unless breaking them is necessary to close a hole. Similarly, if volatile is to be any value added over pinning unstable or testing, it must respect the same commitment. Okay. The purpose of security is to close holes. Given that volatile identifies it's purpose, I say we apply a similar measure. Without the _possibility_ of trading breakage against purpose, we run the risk of futility. But I agree, breakage should not be introduced randomly. I happen to believe that an excessive aversion to controlled breakage can result in more consequential 'accidental' breakages. There is almost always a trade-off. but the case for eventually upgrading to (1+) is compelling: it is only a question of when and how. If
Re: about volatile.d.o/n
sven writes: - volatile.d.o: security and virus scanners, anti-spam software and similarly fast moving software needed mostly on servers - volatile.d.o: security and virus scanners, anti-spam software and similarly fast moving software - backports.d.o: New (versions of) user interface software (new KDE, new Mozilla and the like) - backports.d.o: New (versions of) software (new KDE, new Mozilla and the like) Both might need security team support, which I would think is difficult for the later. I would say that both _require_ security team support, and are not worth doing if it is not available. -- John Hasler
Re: about volatile.d.o/n
On Tue, Oct 12, 2004 at 05:02:23PM +0200, Sven Mueller wrote: Henning Makholm [u] wrote on 12/10/2004 16:05: For instance, suppose there are Packages A and B in volatile. (A) has an interface (1) that is only used by (B) in the whole of debian. In the whole of Debian is not the only concern here; I would say it is not even relevant. Admins of un*x systems are *supposed* to write a truckload of local scripts to adapt their system to their wishes. That's the way it works. And our commitment in calling stable stable is that those local scripts will keep working across security updates, unless breaking them is necessary to close a hole. Similarly, if volatile is to be any value added over pinning unstable or testing, it must respect the same commitment. If you put it that way, I have to agree with you. However, I would make one restriction: - packages in volatile have to keep their commandline (both input and output) interfaces compatible, would that be 'have to' as in 'MUST'? define compatible. but may change C/Python/Perl interfaces if no unresolved incompatibility in the whole of Debian is created that way. Yeah I've never liked those C/Python/Perl people either, not enough soldering irons! ;) However, as far as possible, what is the basis for the trade-off. they _should_ also keep those compatible. so that's just a bug then? An exception can be made (like you said) if a change in interface is needed to close a security whole. Taken as read. Another reason for exception is an addition to the interface (as little interfering as possible) to allow scanning for and reporting of new security holes or viruses (for security/virus scanners). This is part of the definition of compatible? If upgrading will break existing interfaces, then when means after the current testing freezes and is released as stable. Like I said above, I generally agree. But I would only expect scripting interfaces in the meaning of commandline interfaces to remain compatible. If a sysadmin writes scripts which depend on an actual API, I think it is reasonable for him(/her) to track changes in the APIs (s)he is using and/or to mark the packages containing those APIs as hold. more generally, and a point I was trying to make before: If one wishes to make guarantees about APIs then it might be good to identify the APIs. It is surprising how much people's opinions can vary in the edge-cases, and too much hand-waving is bad for the circulation. (okay, so I made the last part up). Sven, you're clearly having a good crack at that here. You've said mozilla belongs in backports, which I'll take to mean: mozilla does not belong in volatile. I'm saying that *new upstream versions* of mozilla with hundreds of little interface changes, new preferences file formats, et cetera, does not belong in volatile. OK, I would like to see it implemented approx. like this (names subject to change): - volatile.d.o: security and virus scanners, anti-spam software and similarly fast moving software needed mostly on servers - backports.d.o: New (versions of) user interface software (new KDE, new Mozilla and the like) Both might need security team support, which I would think is difficult for the later. Depending on how big it is I imagine. Certainly, when staying close to upstream versions, one hopes to have a relatively easy time applying security fixes (or even just upgrading to the next version). I'm inclined to think that packages like mozilla belong in stable or backports, because I can't see why they _have_ to be volatile. I don't think being immature software would make a good criterion for entry. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
paddy [u] wrote on 12/10/2004 18:14: If you put it that way, I have to agree with you. However, I would make one restriction: - packages in volatile have to keep their commandline (both input and output) interfaces compatible, would that be 'have to' as in 'MUST'? Yes. define compatible. Not really a good definition, but explains what I have in mind: If package A is updated, for it to still keep compatibility, the following needs to be fulfilled: Any pre-existing piece of software (let's call it X) which interfaces with A must stay fully functional. New features may be added to A and might not be available via the original interface, but any feature previously available must still work in the same way (less bugs being fixed). This also means that spelling mistakes in the C locale must be preserved (they may get fixed in other locales though, including en_US) as well as any (possibly even weird) output formatting. That last sentence also implies that any script using the commandline interface of A must reset LC_ALL and LANG to C or unset it. Otherwise the output format and wording might change from one revision to the other. This is good practise anyway, since you couldn't rely on a specific output formatting or wording without specifically setting a well-known locale. but may change C/Python/Perl interfaces if no unresolved incompatibility in the whole of Debian is created that way. Yeah I've never liked those C/Python/Perl people either, not enough soldering irons! ;) grin It wasn't meant that way. But I think that locally written scripts shouldn't directly use the Perl module API (as in Mail::SpamAssassin for example) but use the commandline interface instead. However, as far as possible, what is the basis for the trade-off. You mean where I would draw the line for that? I would want to decide that case-by-case. If the change to the API is minimal and the work for avoiding it is tremendous (or other reasons make it important to incorporate that change), it seems wise to allow it in. they _should_ also keep those compatible. so that's just a bug then? ??? You mean the incompatibility? Suppose so. Another reason for exception is an addition to the interface (as little interfering as possible) to allow scanning for and reporting of new security holes or viruses (for security/virus scanners). This is part of the definition of compatible? In a way, yes. see explanation above. The addition should interfere with existing interfaces as little as possible. If one wishes to make guarantees about APIs then it might be good to identify the APIs. It is surprising how much people's opinions can vary in the edge-cases, and too much hand-waving is bad for the circulation. (okay, so I made the last part up). ;-) API is an application programming interface. So it is not interfering with scripting interfaces (aka commandline interfaces) ;-) Actually I think that any machine readable input/output of a program (at least when called with the C locale selected) is regarded by many people as an API. I don't think so, but I think it should be handled in a similar way, but with rules a (very) little less strict. Sven, you're clearly having a good crack at that here. Sounds like a compliment to me. thanks. :-) OK, I would like to see it implemented approx. like this (names subject to change): - volatile.d.o: security and virus scanners, anti-spam software and similarly fast moving software needed mostly on servers - backports.d.o: New (versions of) user interface software (new KDE, new Mozilla and the like) Both might need security team support, which I would think is difficult for the later. Depending on how big it is I imagine. Certainly, when staying close to upstream versions, one hopes to have a relatively easy time applying security fixes (or even just upgrading to the next version). Yes, staying close to upstream makes it easier to backport their security fixes for certain. But depending on the release practise of upstream, it might not be advisable to always simply update to their newest version. I'm inclined to think that packages like mozilla belong in stable or backports, because I can't see why they _have_ to be volatile. I don't think being immature software would make a good criterion for entry. Right.
Re: about volatile.d.o/n
Henning Makholm [u] wrote on 12/10/2004 15:46: Scripsit Sven Mueller [EMAIL PROTECTED] Henning Makholm [u] wrote on 11/10/2004 20:22: [volatile.debian.org] Security fixes should be handled by security.d.o. Perhaps yes, perhaps no. Security fixes *to* packages already in volatile is a grey area, yes. No argument there I thought I was talking about security fixes to stable packages going in volatilie instead of security.d.o. Certainly. volatile should _not_ be just another security archive. Security fixes to packages in stable should go to security.d.o as they used to. Volatile might get updated due to the same security problem, but if so, then that would most likely be by an upgrade to a fixed upstream version instead of a backport of that specific security fix. _If_ the new upstream version is stable and doesn't break compatibility (in a way contradicted by volatile policy). cu, sven
Re: about volatile.d.o/n
Scripsit paddy [EMAIL PROTECTED] On Tue, Oct 12, 2004 at 03:05:05PM +0100, Henning Makholm wrote: But isn't volatile.d.o supposed to *be* the out-of-band mechanism (whatever out-of-band means here)? No. clamav virus signatures, for example, can be maintained by a program, freshclam, that downloads database updates from upstream. I know that, but as far as I under stande, the whole point of volatile is to replace exactly that with a situation where each maintainer does not have do program his own freshfoo system (and worry about finding a location to download from that is known in advance to stay availbale throughout the entire lifetime of the next stable release). I don't see how that means that there wouldn't be a need for rule updates. See above. The consensus seems to be that it would be undesirable to even try to push this data through the regular package-management channel. Whose consensus is this? The debian-devel feed that reaches me shows quite enthusiastic support for pushing rule updates through an aptable repository. And in any case the point is that I want to run a *stable* box. I am not keeping consciously track with upstream changes to background software like spam filters, so I didn't *know* that a 3.0 version was about to happen. A user of stable should be *able* to remain ignorant about such chages. Ah, but you weren't just a user of stable were you? You'd drunk from the forbidden waters of unstable! :) Because volatile does not currently exist. The point is to get improved *classification* without changing the *interfaces*. For me the point is to achieve function. Function may disappear totally if the update makes things break. If upgrading will break existing interfaces, then when means after the current testing freezes and is released as stable. Yes, for stable. Do we want 'just another stable' ? No, we want a way to push non-breaking data updates to stable users in a controlled way. They'll still be stable users, so they still want freedom from gratuitous breaking. If you s/mozilla/spamassassin/ I might want to argue the point. Well, I don't want to se an update to spamassassin in volatile if it breaks APIs that my scripts use. Raising spam detection rates from 97% to 98% is useless if the update makes my mail system go catatonic and deliver all incoming mail, spam or not, to /dev/null. I run stable on my mail server because I *don't* want random breakage, and if not having any random breakage means that I'll have do delete a bit more of my spam by hand, then so be it. If I wanted random breakage, I'd run testing on the server. But I don't. Why are we talking about mozilla? I don't know. You seem to have some kind of point about it, but I still cannot fathom what it is. -- Henning Makholm Occam was a medieval old fart. The simplest explanation that fits the facts is always, God did it.
Re: about volatile.d.o/n
Hi, Christoph Berg wrote:
Re: Henning Makholm in [EMAIL PROTECTED]
Some things are not so obvious:
Should volatile include updates of packages such as debian-keyring?
debian-policy and developers-reference?
Those who need these packages will run Sid anyway.
I hope I'll be able not to do that, for a while at least.
... well, except for the fact that I'm already a happy user of
spamassassin 3 ...
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Re: about volatile.d.o/n
Sven Mueller [EMAIL PROTECTED] writes: Any pre-existing piece of software (let's call it X) which interfaces with A must stay fully functional. New features may be added to A and might not be available via the original interface, but any feature previously available must still work in the same way (less bugs being fixed). This also means that spelling mistakes in the C locale must be preserved (they may get fixed in other locales though, including en_US) as well as any (possibly even weird) output formatting. That last sentence also implies that any script using the commandline interface of A must reset LC_ALL and LANG to C or unset it. Otherwise the output format and wording might change from one revision to the other. This is good practise anyway, since you couldn't rely on a specific output formatting or wording without specifically setting a well-known locale. No. It must behave identically, regardless of locale. Spelling fixes in the interface *cannot* be part of what the new version needs in order to remain useful. This is just the kind of dogde that has been worrying me about these proposals. Thomas
Re: about volatile.d.o/n
martin f krafft [EMAIL PROTECTED] schrieb: also sprach Marco d'Itri [EMAIL PROTECTED] [2004.10.08.2029 +0200]: Is looking up .org domains in the wrong whois server enough to be considered useless? I found it rather useless in woody when the .org registrar changed. I'd say it is a bug in whois to ship this information in the binary, instead of some file in /etc/. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: about volatile.d.o/n
* Florian Weimer ([EMAIL PROTECTED]) [041010 16:40]: * Andreas Barth: - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; Can volatile receive critical updates which are usually not applied to stable because backports are not available for some reason? Are you speaking about mozilla? ;) Well, that's definitly not the first purpose of volatile, and so, I would like to postpone it a bit. However, in the long run, I think you're right about adding newer packages if they fix security issues, and we can't fix them otherwise. But I think it needs more than just some consideration how to do this in a non-breaking way. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
Christoph Berg [EMAIL PROTECTED] wrote: Re: Henning Makholm in [EMAIL PROTECTED] Should volatile include updates of packages such as debian-keyring? debian-policy and developers-reference? Those who need these packages will run Sid anyway. I'd sincerely hope not. The fact that few developers run stable is a contributing factor to the lack of motiviation towards releasing. I don't think many people understand just how old stable currently is. Where possible, I think developers should be encouraged to run at least one stable box... -- Matthew Garrett | [EMAIL PROTECTED]
Re: about volatile.d.o/n
* Andreas Barth: Can volatile receive critical updates which are usually not applied to stable because backports are not available for some reason? Are you speaking about mozilla? ;) Mozilla, GnuPG, and maybe even PHP 4, depending on sarge's lifetime. Other complex packages can easily enter this state, too, especially when sarge has been around for a year or two. Actually, Mozilla's situation is beginning to look rather promising. The distributor community seems to pick up the challenge and issue patches. Of course, if we release 1.6 with sarge (a version that is officially unsupported by upstream), we might not be able to profit from this development. However, in the long run, I think you're right about adding newer packages if they fix security issues, and we can't fix them otherwise. But I think it needs more than just some consideration how to do this in a non-breaking way. I agree that this has to be decided on a case-by-case basis.
Re: about volatile.d.o/n
Martin Zobel-Helas [EMAIL PROTECTED] wrote: i would like to see some policy, what, when and under which circumstances gets included to volatile.d.n. The most sensible policy would be a case by case consideration. Some packages can sanely have the desired features backported [1], and some can't [2]. It's possible that we /could/ write policy that would actually be able to differentiate between the two cases, but it's fairly likely that it would just end up devolving into flamewars about corner cases or misclassification. I'd suggest a team of reasonable people who we trust to make the decisions and liase with package maintainers as appropriate. It's much less effort and it involves much less unhappiness. [1] whois would probably be a good example - if the set of whois servers is suddenly altered, the right thing to do is to change the list rather than update to the latest version [2] If sensible spamassassin functionality is based on a new parsing engine, then backporting that functionality to the old parsing engine may be impossible and is certainly going to involve a sufficiently large amount of new and untested code that any claims about enhanced stability aren't going to be massively convincing -- Matthew Garrett | [EMAIL PROTECTED]
Re: about volatile.d.o/n
Daniel Burrows [EMAIL PROTECTED] wrote: I generally have to resort to backports or unstable when installing Debia= n=20 on recent hardware, because we don't update hardware drivers in stable. =20 Would the kernel and X be candidates for volatile? I think those are arguments for making releases more quickly, rather than anything else. It's a subtley different argument to the volatile one. -- Matthew Garrett | [EMAIL PROTECTED]
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 10:42:58AM +0100, Matthew Garrett wrote: Daniel Burrows [EMAIL PROTECTED] wrote: I generally have to resort to backports or unstable when installing Debia= n=20 on recent hardware, because we don't update hardware drivers in stable. =20 Would the kernel and X be candidates for volatile? I think those are arguments for making releases more quickly, rather than anything else. I'm not sure about that, graphics hardware, for example, is far faster moving than stable. And there are forces pulling both ways on the stable release cycle. The kernel and X are both at least somewhat modular, how unrealistic is it to think in terms of backporting just the drivers ? And would that be better? It's a subtley different argument to the volatile one. Agreed. Not useless, simply not useful. ;) Most of us must encounter this, I think in terms of 'choose your poison'. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: Hi all, we had some discussion about volatile, and I'm more and more considering to pick this task up. I think some issues are quite obvious: - packages should only go in in cooperation with the maintainers; - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; Andi, I would like 'must' keep them functional: IOW, voltaile is prepared to drop packages from volatile that are, for whatever reason, unable to keep up with the purpose. It would be sad if volatile ended up containing useless packages! Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
paddy [EMAIL PROTECTED] wrote: On Mon, Oct 11, 2004 at 10:42:58AM +0100, Matthew Garrett wrote: I think those are arguments for making releases more quickly, rather than anything else. I'm not sure about that, graphics hardware, for example, is far faster moving than stable. And there are forces pulling both ways on the stable release cycle. If we aimed at a new stable release about once a year (which obviously requires providing support for more than one release at once, but still), that would be much less of a problem. The kernel and X are both at least somewhat modular, how unrealistic is it to think in terms of backporting just the drivers ? And would that be better? Adding new drivers is usually fairly easy and probably wouldn't cause any problems. Backporting more recent versions of existing drivers isn't desperately hard, but newer drivers frequently cause regressions in existing hardware support. Without going through a full release cycle, it's difficult to track down whether or not something has broken. -- Matthew Garrett | [EMAIL PROTECTED]
Re: about volatile.d.o/n
Matthew Garrett [EMAIL PROTECTED] schrieb: Christoph Berg [EMAIL PROTECTED] wrote: Re: Henning Makholm in [EMAIL PROTECTED] Should volatile include updates of packages such as debian-keyring? debian-policy and developers-reference? Those who need these packages will run Sid anyway. I'd sincerely hope not. The fact that few developers run stable is a contributing factor to the lack of motiviation towards releasing. I don't think many people understand just how old stable currently is. Where possible, I think developers should be encouraged to run at least one stable box... Which would be painful to use. Some backports - e.g. Adrian Bunk's collection - are really advisable. But even then you know how old woody is. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 11:42:57AM +0100, Matthew Garrett wrote: paddy [EMAIL PROTECTED] wrote: On Mon, Oct 11, 2004 at 10:42:58AM +0100, Matthew Garrett wrote: I think those are arguments for making releases more quickly, rather than anything else. I'm not sure about that, graphics hardware, for example, is far faster moving than stable. And there are forces pulling both ways on the stable release cycle. If we aimed at a new stable release about once a year (which obviously requires providing support for more than one release at once, but still), that would be much less of a problem. I'm wondering if the long-term solution may be to extend security.d.o support for some important subset (say standard, for the sake of argument), allowing the main release cycle a little more freedom to float to a different level if that is where it wants to go. The kernel and X are both at least somewhat modular, how unrealistic is it to think in terms of backporting just the drivers ? And would that be better? Adding new drivers is usually fairly easy and probably wouldn't cause any problems. Backporting more recent versions of existing drivers isn't desperately hard, That's good ... but newer drivers frequently cause regressions in existing hardware support. Without going through a full release cycle, it's difficult to track down whether or not something has broken. If all drivers are in one large package, then this is a huge problem, but if they can be packaged individually, much less so I think. Even without individual packaging, volatile might one-day still make a home for such things (but I _won't_ be helping! :) It it easy to imagine how one might admit a single driver onto the volatile archive ... Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
Andi, On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: - It should allow any administrator to just use volatile, as they just use security.d.o, and they should be confident that nothing is broken by that; It would be great to get some clarification of this. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
* paddy ([EMAIL PROTECTED]) [041011 12:55]: On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; I would like 'must' keep them functional: IOW, voltaile is prepared to drop packages from volatile that are, for whatever reason, unable to keep up with the purpose. It would be sad if volatile ended up containing useless packages! Of course we need to reserve the right to drop packages - but, doing that would still be bad. Adding a package to volatile means for me that we are very confident that we can support it till the current debian major release is archived. If we can't do that, we shouldn't have added it in the first place. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 02:02:47PM +0200, Andreas Barth wrote: * paddy ([EMAIL PROTECTED]) [041011 12:55]: On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; I would like 'must' keep them functional: IOW, voltaile is prepared to drop packages from volatile that are, for whatever reason, unable to keep up with the purpose. It would be sad if volatile ended up containing useless packages! Of course we need to reserve the right to drop packages - but, doing that would still be bad. Adding a package to volatile means for me that we are very confident that we can support it till the current debian major release is archived. If we can't do that, we shouldn't have added it in the first place. Hmm, deja vu ;) What happens to packages that become orphaned? Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
* paddy ([EMAIL PROTECTED]) [041011 15:35]: On Mon, Oct 11, 2004 at 02:02:47PM +0200, Andreas Barth wrote: Of course we need to reserve the right to drop packages - but, doing that would still be bad. Adding a package to volatile means for me that we are very confident that we can support it till the current debian major release is archived. If we can't do that, we shouldn't have added it in the first place. Hmm, deja vu ;) What happens to packages that become orphaned? The same that happens with them in stable. The volatile team has to keep care of them till the current debian major release is archived. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 03:37:21PM +0200, Andreas Barth wrote: * paddy ([EMAIL PROTECTED]) [041011 15:35]: On Mon, Oct 11, 2004 at 02:02:47PM +0200, Andreas Barth wrote: Of course we need to reserve the right to drop packages - but, doing that would still be bad. Adding a package to volatile means for me that we are very confident that we can support it till the current debian major release is archived. If we can't do that, we shouldn't have added it in the first place. Hmm, deja vu ;) What happens to packages that become orphaned? The same that happens with them in stable. The volatile team has to keep care of them till the current debian major release is archived. Given that the volatile team is the gatekeeper to the volatile archive, this is an excellent approach: packages are unlikely to get in too easily. It's also a big commitment: kudos once again for stepping up to the plate. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
Scripsit Florian Weimer [EMAIL PROTECTED] Can volatile receive critical updates which are usually not applied to stable because backports are not available for some reason? Mozilla, GnuPG, and maybe even PHP 4, depending on sarge's lifetime. Other complex packages can easily enter this state, too, especially when sarge has been around for a year or two. I would advise not trying to overloade volatile with too many meanings. A backport of a new Mozilla release is something vastly different from new rules for a spam filter, and I see little value in lumping them together in the same add-on repository. I would like to see a volatile with a very strict mandate: 1. Volatile is a means for *pushing* updates to stable installations, where such updates are necessary for *preserving* the utility of packages due to changes of the outside world. 2. Necessary for preserving the utility should be judged under the assumption that the machine that runs stable does not itself change. (I.e., appeals to this is needed for modern hardware don't count). 3. No update pushed through volatile should ever change any user interfaces or programmatic interface. (How paranoid developers are expected to be in ensuring this is negotiable, but it must at least be the *goal* that no interfaces change.) The goal should be that I, as a user, can add volatile to my sources.list and periodically do an apt-get upgrade - without risking to suddenly have my web browser updated to a new major release where it starts behaving differently, all my users' preferences get out of kilter, etc. If I run a web browser on a stable machine, it is because I am satisfied with its behavior and capabilities. If I want a newer one, I can go to a regular backports repository and pick one by hand. I do not want to get a new version pushed at me simply because it becomes available. If I wanted that kind of behavior I would run testing or unstable, not stable. An update of mozilla-browser would be appropriate for volatile if it did not change the upstream codebase, but, say, updated the default SSL root certificate set in response to announcements from a well-known CA. An update that fixed the default style sheet to include new tags from XHTML 2.1, assuming that it was possible without code changes, would be borderline. Anything more involved than that - no thanks. -- Henning Makholm Punctuation, is? fun!
Re: about volatile.d.o/n
* Henning Makholm ([EMAIL PROTECTED]) [041011 18:30]: The goal should be that I, as a user, can add volatile to my sources.list and periodically do an apt-get upgrade - without risking to suddenly have my web browser updated to a new major release where it starts behaving differently, all my users' preferences get out of kilter, etc. I think this is one of the most important statements - and I think it describes our policy quite well. I could however see the possiblity to add a new package mozilla1.7, that users can optionally install. However, I also won't like it. cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
Henning Makholm writes: 1. Volatile is a means for *pushing* updates to stable installations, where such updates are necessary for *preserving* the utility of packages due to changes of the outside world. 2. Necessary for preserving the utility should be judged under the assumption that the machine that runs stable does not itself change. (I.e., appeals to this is needed for modern hardware don't count). 3. No update pushed through volatile should ever change any user interfaces or programmatic interface. (How paranoid developers are expected to be in ensuring this is negotiable, but it must at least be the *goal* that no interfaces change.) ... An update of mozilla-browser would be appropriate for volatile if it did not change the upstream codebase, but, say, updated the default SSL root certificate set in response to announcements from a well-known CA. An update that fixed the default style sheet to include new tags from XHTML 2.1, assuming that it was possible without code changes, would be borderline. Anything more involved than that - no thanks. Sounds about right to me. -- John Hasler
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 05:06:21PM +0100, Henning Makholm wrote: Scripsit Florian Weimer [EMAIL PROTECTED] Can volatile receive critical updates which are usually not applied to stable because backports are not available for some reason? Mozilla, GnuPG, and maybe even PHP 4, depending on sarge's lifetime. Other complex packages can easily enter this state, too, especially when sarge has been around for a year or two. I would advise not trying to overloade volatile with too many meanings. Agreed. I think its hard enough establishing a simple meaning. But these issues have been bubbling and motivating in this area for some time, perhaps there will be more room at the inn soon? A backport of a new Mozilla release is something vastly different from new rules for a spam filter, To be fair, the issue is that if were just rules, there wouldn't be a need. and I see little value in lumping them together in the same add-on repository. risky. but there may be some synergies. And then there is the potential cost of a profusion of little repositories. Whatever the solution is to the mozilla problem, there does at least appear to be consensus that there has been one. I would like to see a volatile with a very strict mandate: 1. Volatile is a means for *pushing* updates to stable installations, where such updates are necessary for *preserving* the utility of packages due to changes of the outside world. Of course the outside world is where new hardware becomes available ;) 2. Necessary for preserving the utility should be judged under the assumption that the machine that runs stable does not itself change. (I.e., appeals to this is needed for modern hardware don't count). Excellent. This really makes the distinction. Not that I care one way or another whether drivers can enter volatile, but the lack of a good distinction was really bothering me. 3. No update pushed through volatile should ever change any user interfaces or programmatic interface. (How paranoid developers are expected to be in ensuring this is negotiable, but it must at least be the *goal* that no interfaces change.) This is still blurry for me, although I agree with your example. Let me offer examples of real-life changes and their impact: MailScanner can be configured to send mail to an admin account warning of various events. I filter these with procmail. Recently these warnings changed. I would not want a volatile maintainer to be hamstrung in such a case if no package in debian uses the interface: I made the mess, I can fix it (and I will, soon ... :) (Also: which would you rather have backward-compatibility or forward-compatibility? depends on how much past you have and what future you see) Clearly the names of virus identifications sometimes change. This is expected. I would say that the interface is _defined_ as volatile. But these are at one extreme, clamav not dragging sendmail into the archive is at another, and you are identifying important ground in the middle. The goal should be that I, as a user, can add volatile to my sources.list and periodically do an apt-get upgrade Personally, if use it (as I hope to), it will be only for specific packages. - without risking to suddenly have my web browser updated to a new major release where it starts behaving differently, all my users' preferences get out of kilter, etc. If I run a web browser on a stable machine, it is because I am satisfied with its behavior and capabilities. This sounds quite hectic, I'm begining to feel all dizzy. If I want a newer one, I can go to a regular backports repository and pick one by hand. I do not want to get a new version pushed at me simply because it becomes available. If I wanted that kind of behavior I would run testing or unstable, not stable. Ah, that's much better. Playing the devil's advocate: Someone's going to say so don't do that then aren't they. Are you saying you have a use for a volatile mozilla, or simply that you see potential problems? If it's the latter, then I agree, you have identified a potential problem area. Also: for a web-browser, yes. For applications in more voltile domains I'm willing to be a little more flexible. But that's just me. Is it practical, or even possible, to identify the use-cases for a web-browser in volatile, to shed more light on what users actually want? Hell, do we care what users want (only kidding folks!) An update of mozilla-browser would be appropriate for volatile if it did not change the upstream codebase, but, say, updated the default SSL root certificate set in response to announcements from a well-known CA. It would seem a shame to have to do a whole mozilla-browser package just for that. An update that fixed the default style sheet to include new tags from XHTML 2.1, assuming that it was possible without code
Re: about volatile.d.o/n
Andreas Barth writes: I could however see the possiblity to add a new package mozilla1.7, that users can optionally install. However, I also won't like it. I see no reason for new packages to ever go into volatile. Such things belong in backports. -- John Hasler
Re: about volatile.d.o/n
* John Hasler ([EMAIL PROTECTED]) [041011 19:55]: Andreas Barth writes: I could however see the possiblity to add a new package mozilla1.7, that users can optionally install. However, I also won't like it. I see no reason for new packages to ever go into volatile. Such things belong in backports. If we really say: Well, we recommend to upgrade your package to the newest version., _than_ I think adding it to volatile may be ok. However, certainly a border case, and certainly not the most important thing to start off (so, IMHO, we can just postpone the discussion about, and start with the things we all agree about). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
Scripsit Andreas Barth [EMAIL PROTECTED] I could however see the possiblity to add a new package mozilla1.7, that users can optionally install. However, I also won't like it. Me neither. For example, if I was already using somebody else's backport of mozilla1.7, I wouldn't like it if volatile.d.o hijacked that package and attempted to update it with maintainer scripts that know nothing about the backport I'm using. All additions of new packages carry such a risk, and I don't think that volatile should take that risk unless demonstrably necessary for reaching the main goal of volatile. Which is not duplicating something that existing backports repositories do well. (For the same reason, any updates that add any _new_ /usr/lib/*.so files should be treated with extreme caution. Their name may clash with something I have in /usr/local/lib, and break things. On the other hand /usr/lib/packagename/*.so is fair game). -- Henning Makholm ... popping pussies into pies Wouldn't do in my shop just the thought of it's enough to make you sick and I'm telling you them pussy cats is quick ...
Re: about volatile.d.o/n
paddy writes: Whatever the solution is to the mozilla problem, there does at least appear to be consensus that there has been one. IMO Mozilla belongs in something like backports.debian.org. -- John Hasler
Re: about volatile.d.o/n
Scripsit paddy [EMAIL PROTECTED] On Mon, Oct 11, 2004 at 05:06:21PM +0100, Henning Makholm wrote: A backport of a new Mozilla release is something vastly different from new rules for a spam filter, To be fair, the issue is that if were just rules, there wouldn't be a need. Why not? I pretty much want to have the spamfilter rules on my mail box updated from time to time. Currently that has lead me to put a low-pinned unstable in sources.list and get spamassassin from there. But it was not meant to suddenly pull in spamassassin3. If volatile had existed, I could have avoided that. MailScanner can be configured to send mail to an admin account warning of various events. I filter these with procmail. Recently these warnings changed. I would not want a volatile maintainer to be hamstrung in such a case if no package in debian uses the interface: I disagree here. One of the main reasons to run stable (apart from getting security updates) is that one can be sure that one's homegrown scripts will not suddenly stop working because some of the Debian-provided software changes the behavior. That means that updates should avoid *any* unnecessary interface changes, right down to preserving spelling errors in the messages used by the intially released version. Volatile should preserve that stability guarantee and stick to changing the internal processing to be up-to-date with the changed world. Clearly the names of virus identifications sometimes change. This is expected. I would say that the interface is _defined_ as volatile. Clearly, but the *format* in which the virus scanner reports its findings should stay stable. Playing the devil's advocate: Someone's going to say so don't do that then aren't they. They probably are, at least until we can agree what is and what is not the purpose of the facility. I'm arguing what *should* be the purpose. Are you saying you have a use for a volatile mozilla, or simply that you see potential problems? If it's the latter, then I agree, you have identified a potential problem area. I'm not sure that I understand that question. Also: for a web-browser, yes. For applications in more voltile domains I'm willing to be a little more flexible. But that's just me. Do you have an concrete example we can use to discuss where the line should be drawn? An update of mozilla-browser would be appropriate for volatile if it did not change the upstream codebase, but, say, updated the default SSL root certificate set in response to announcements from a well-known CA. It would seem a shame to have to do a whole mozilla-browser package just for that. First example that came to mind. A smart maintainer who anticipates doing such an update would probably separate out the root certificates in a small package that could be shared with other PKI-using packages. For all I know, this may already be how it works currently; I did not spend much time tracing the dependencies of the various mozilla packages. I think what you're saying is you don't want the browser to change very much. Yes. If it makes the keyboard shortcuts I'm used to work differently, then it's too much. I don't know how important fixing 'the default style sheet to include new tags from XHTML 2.1' is, but it sounds pretty unimportant to me. Yes. The point was that if somebody cared enough to do a volatile update for it I wouldn't find it totally out of line. But I would not expect anybody to care that much. Presumably, security fixes are more important. Security fixes should be handled by security.d.o. There may or may not be somebody who claims that they *are* not handled by s.d.o (I haven't seen that, but I haven't looked for it either). Even if true, that does not change the fact that s.d.o is where it *should* be handled. Introducing volatile just to make it a competing security team would be silly. I don't see any need to place obstacles in the way just in case. And I'm concerned that those obstacles might ultimately get in the way of packages _in_ volatile (when we have some). I'm not proposing any mozilla-specific obstacles, at least as not as far as I'm aware. -- Henning Makholm Slip den panserraket og læg dig på jorden med ansigtet nedad!
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 01:13:40PM -0500, John Hasler wrote: paddy writes: Whatever the solution is to the mozilla problem, there does at least appear to be consensus that there has been one. IMO Mozilla belongs in something like backports.debian.org. It's certainly not in the category of applications that I'm interested in seeing in volatile. I'm over the moon at what _is_ happening. Happily, Andi appears open-minded, but focused on the hard work of doing the 'obviously right' things first. There is a plenty of uncontroversial work to do, I think we can worry about mozilla if the need ever arises. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
* paddy ([EMAIL PROTECTED]) [041011 21:00]: Happily, Andi appears open-minded, but focused on the hard work of doing the 'obviously right' things first. Well, I'm just waiting for maintainers to say: Yes, please include a more uptodate version of my package foo. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 07:22:15PM +0100, Henning Makholm wrote: Scripsit paddy [EMAIL PROTECTED] On Mon, Oct 11, 2004 at 05:06:21PM +0100, Henning Makholm wrote: A backport of a new Mozilla release is something vastly different from new rules for a spam filter, To be fair, the issue is that if were just rules, there wouldn't be a need. Why not? Well, the argument goes: that can be done out-of-band, but some updates involve changes or additions to the engine. There is a class of such software. I pretty much want to have the spamfilter rules on my mail box updated from time to time. I understand that. Each of us has differing needs. Currently that has lead me to put a low-pinned unstable in sources.list and get spamassassin from there. But it was not meant to suddenly pull in spamassassin3. If volatile had existed, I could have avoided that. Ouch. I agree that there are dificulties with pinning up to unstable. Did spamassassin3 go into unstable as 'spamassasin'? (I've not been paying attention) I bet a few people were caught out by this! SA3 has been on the cards for some time now. Is there a policy around name changes at these times? could you have pinned (3.0) ? At the end of the day, I'm not certain exactly what you wanted protecting from, but it's hard to be certain that volatile would give it to you. After all the point is to get (at least some) changes. MailScanner can be configured to send mail to an admin account warning of various events. I filter these with procmail. Recently these warnings changed. I would not want a volatile maintainer to be hamstrung in such a case if no package in debian uses the interface: I disagree here. One of the main reasons to run stable (apart from getting security updates) is that one can be sure that one's homegrown scripts will not suddenly stop working because some of the Debian-provided software changes the behavior. That means that updates should avoid *any* unnecessary interface changes, right down to preserving spelling errors in the messages used by the intially released version. Yes. I can certainly see your point here, and would be more than happy with a volatile where this was the case. I simply see both sides of the coin. Even when the edges get very blurred. And I think they can. Volatile should preserve that stability guarantee and stick to changing the internal processing to be up-to-date with the changed world. Clearly the names of virus identifications sometimes change. This is expected. I would say that the interface is _defined_ as volatile. Clearly, but the *format* in which the virus scanner reports its findings should stay stable. You'll get no argument from me on the priciple of that. But what is stable? What if a format needs extending to take account of some new circumstance? I can go on in this vein... For instance, suppose there are Packages A and B in volatile. (A) has an interface (1) that is only used by (B) in the whole of debian. Vital new functionality is added to (A) impacting only (1). Upstream (B) is updated to use the new (1). Functionality will suffer seriously if the new (1) is not implemented. The maintainer(s) may want to take steps to zero the impact on existing users, but the case for eventually upgrading to (1+) is compelling: it is only a question of when and how. In extremis, backporting can become a destabilising activity. Playing the devil's advocate: Someone's going to say so don't do that then aren't they. They probably are, at least until we can agree what is and what is not the purpose of the facility. I'm arguing what *should* be the purpose. fair enough, I couldn't resist :) Are you saying you have a use for a volatile mozilla, or simply that you see potential problems? If it's the latter, then I agree, you have identified a potential problem area. I'm not sure that I understand that question. Yeah, sorry, looking back it wasn't terribly polite. sigh I must learn some manners. You've said mozilla belongs in backports, which I'll take to mean: mozilla does not belong in volatile. So you're not advocating mozilla in volatile. It may be that someone will come along that will advocate it in a compelling fashion, but I'm not holding my breath. Until then, if no one is building it, then what is there to knock down ? Should anyone do so you've pointed out a potential problem area. I'd like to think that the potential problem for users of mozilla is not the same for users of clamav because the users are different. But it may be that you mean this example with wider application, hence the inquiry and my interest. Also: for a web-browser, yes. For applications in more voltile domains I'm willing to be a little more flexible. But that's just me. Do you have an concrete example we can use to discuss where the line should be drawn? If we are to succeed in
Re: about volatile.d.o/n
Andi, On Mon, Oct 11, 2004 at 09:01:41PM +0200, Andreas Barth wrote: * paddy ([EMAIL PROTECTED]) [041011 21:00]: Happily, Andi appears open-minded, but focused on the hard work of doing the 'obviously right' things first. Well, I'm just waiting for maintainers to say: Yes, please include a more uptodate version of my package foo. I would say that's 'obviously right'. It could be worse: If I were maintainer, _I_ would be volunteering. Now I wouldn't wish that on anybody :) Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
This one time, at band camp, John Hasler said: Henning Makholm writes: 1. Volatile is a means for *pushing* updates to stable installations, where such updates are necessary for *preserving* the utility of packages due to changes of the outside world. 2. Necessary for preserving the utility should be judged under the assumption that the machine that runs stable does not itself change. (I.e., appeals to this is needed for modern hardware don't count). 3. No update pushed through volatile should ever change any user interfaces or programmatic interface. (How paranoid developers are expected to be in ensuring this is negotiable, but it must at least be the *goal* that no interfaces change.) ... An update of mozilla-browser would be appropriate for volatile if it did not change the upstream codebase, but, say, updated the default SSL root certificate set in response to announcements from a well-known CA. An update that fixed the default style sheet to include new tags from XHTML 2.1, assuming that it was possible without code changes, would be borderline. Anything more involved than that - no thanks. Sounds about right to me. AOL. Thanks, Henning, for saying it so much better than I could. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp5hMEkqM8u4.pgp Description: PGP signature
Re: about volatile.d.o/n
Henning Makholm [u] wrote on 11/10/2004 19:48: Scripsit Andreas Barth [EMAIL PROTECTED] I could however see the possiblity to add a new package mozilla1.7, that users can optionally install. However, I also won't like it. Me neither. For example, if I was already using somebody else's backport of mozilla1.7, I wouldn't like it if volatile.d.o hijacked that package and attempted to update it with maintainer scripts that know nothing about the backport I'm using. Either you are using a backport, which implies that the version you are using is actually somewhere in the debian archive (probably testing or unstable) or you are using an unofficial package in which case Debian can't help you. It is impossible to tell which unofficial packages are available. www.apt-get.org does quite a good job at listing most unofficial repositories, but I don't think that volatile.d.o should actually check each of them for possible clashes with software entering v.d.o. If you install something unofficial on your system and it breaks because of some conflicting version/package in the official archive (be it main, non-us, security or the proposed volatile), this is _your_ problem or that of the provider of that unofficial package, not Debian's. If you are using a backport from backports.org, there won't be a problem, but if there was one, it would still not be up to Debian, but to the backporter. regards, Sven PS: Sorry, didn't mean to send this reply in private first.
Re: about volatile.d.o/n
Henning Makholm [u] wrote on 11/10/2004 20:22: [volatile.debian.org] Security fixes should be handled by security.d.o. Perhaps yes, perhaps no. At least it should follow two rules: 1) If not handled by security.d.o, it should at least be handled in close cooperation with security.d.o 2) It has to have a seperate security archive so that a security fix for a package in v.d.o does not cause a package from the main stable release to be updated. What I mean by the second rule is that if I have to put deb http://volatile.debian.org stable main contrib into sources.list, I would also need to put deb http://security.debian.org volatile/stable main contrib there to fetch the security fixes. I don't want the normal stable security deb line to cause security updates to v.d.o to be fetched. cu, sven
Re: about volatile.d.o/n
Jesus Climent [u] wrote on 09/10/2004 02:28: On Fri, Oct 08, 2004 at 03:51:29PM -0400, Daniel Burrows wrote: I generally have to resort to backports or unstable when installing Debian on recent hardware, because we don't update hardware drivers in stable. Would the kernel and X be candidates for volatile? I dont see any reason why not, if they can be marked as NotAutomatic. I certainly see reason not to include X in colatile. X pulls in xlibs, and xlibs is depended on by a _huge_ amount of programs if I'm not mistaken. It is near impossible to tell wether an X upgrade might break things or not. As for the kernel: If I were a volatile RM-aequivalent, I might consider getting the kernel into v.d.o, even though it is a huge beast, it usually either breaks completely on some specific system or it doesn't break anything. But I'm not sure about this. regards, Sven
Re: about volatile.d.o/n
This one time, at band camp, Kevin Mark said:
On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote:
This one time, at band camp, Kevin Mark said:
On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote:
On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote:
Packages like virus checkers seem to be
composed of 2 parts: the app program and the data where the data in
this case are virus sigs and the app is say clamav. And the 'volitile'
part is the virus sigs whereas the app (once it hits stable) shouldnt
change unless it warrents a 'security' update. So, volitile should be
for the data/virus sigs that need updating when new bugs hit the 'net.
No, often such kind of programs need engine update. That's true for
both AV and antispam programs as well.
Hi Francesco,
so:
the program = engine part + (some un-named part) ???
and the engine part and the data part are volitile
In the case of clamav, most of the work of scanning is handled by
library functions, and these functions are called by the frontend
programs like clamscan, clamdscan, and the milter.
Hi Stephen,
so,
email
|
\/
{lib}clamav-clamav{frontend}-clamav-{data}
|
\/
mbox
This might be a more helpful diagram:
email
|
MTA---clam frontend
||
| library--data set (sigs)
mbox
Clam doesn't scan email in isolation - it's called by an MTA or a glue
application like amavis. The fact that the underlying library functions
or data sets have changed internally should not matter to the caller, so
long as the front ends have the same API. There is one application I
see outside of the clamav suite that links against libclamav1 directly,
and that will take careful coordination - all the others rely on the API
provided by frontends and will not break so long as the API remains
constant.
would it be good to backport new dataformat to 'stable' dataformat or
risk having to fix {lib} and {frontend}s? then they would be 'unstable'
and need QA?
Not really - clam is dropping the ability to read unsigned datasets, and
while it would be technically possible to recreate signed signature sets
in an older format, the delay introduced by doing so would obviate the
advantage of having automatic updates. Also, clam currently relies on a
worldwide system of mirrors, each of which currently does about 10G of
traffic/month just for the clam updates. Where do you propose we host the
single mirror that will update all of the sarge installs that can't use
the newer data format? I don't have the bandwidth and I don't think
it's practical for p.d.o.
what is the diff between
stable.update,security.update,volitile.update?
enquiring minds what to know? hope this is not too OT!
-Kevin
My understanding is that stable-proposed-updates is for packages that
maintainers would like to see in the next point release, security is for
the security team and contains fixes for packages mentioned in DSA's,
and volatile is intended for packages that need to update more
frequently than point releases allow, but are not directly security
problems, and so are not the arena of the security team.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
pgpf2NIxOcJC4.pgp
Description: PGP signature
Re: about volatile.d.o/n
* Andreas Barth: - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; Can volatile receive critical updates which are usually not applied to stable because backports are not available for some reason?
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 02:28:10AM +0200, Jesus Climent wrote: On Fri, Oct 08, 2004 at 03:51:29PM -0400, Daniel Burrows wrote: I generally have to resort to backports or unstable when installing Debian on recent hardware, because we don't update hardware drivers in stable. Would the kernel and X be candidates for volatile? I dont see any reason why not, if they can be marked as NotAutomatic. Due to versioned dependencies, that could be impractical for X, which has a long list of reverse depends. I'd like to see in volatile just as much as possible 'autoconsistent' pieces of software (to minimize possibility of subtle breakage). Other things have already their home in backports.org, at admin's risk. If you check d-kernel you we'll also see that any new release of kernel would potentially cause problems to a good deal of users. It's not a thing we could seriously think to support IMHO. Also, little is nice: thinking of having a looong list of (complicated and interdependet) volatile packages would imply looong release cycles. That's exactly the opposite we would gain with v.d.o|n. -- Francesco P. Lovergine
Re: about volatile.d.o/n
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: Hi all, we had some discussion about volatile, and I'm more and more considering to pick this task up. I think some issues are quite obvious: - packages should only go in in cooperation with the maintainers; - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; - Good candidates are clamav (including spin-offs), spamassassin, chkrootkit; Hi Andres, I've tried to follow the debate so far, but I'm not as knowledgable as a DD, but I have some thoughts. Packages like virus checkers seem to be composed of 2 parts: the app program and the data where the data in this case are virus sigs and the app is say clamav. And the 'volitile' part is the virus sigs whereas the app (once it hits stable) shouldnt change unless it warrents a 'security' update. So, volitile should be for the data/virus sigs that need updating when new bugs hit the 'net. Does this correspond with what others think? also if the data conformed to the expected format for the version in stable, would it have to go throught the same QA process (expr-unstable-testing-stable)? - -kev - -- (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ Have you mooed today?... -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBZ4y3AWAAuqdWA9cRArSSAJ9RJRIqRuR/TObzU8fAds6E5xR6FACeMyS4 lkNMzUJn7sr6bEdFbZ9hjqc= =zYVC -END PGP SIGNATURE-
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: Packages like virus checkers seem to be composed of 2 parts: the app program and the data where the data in this case are virus sigs and the app is say clamav. And the 'volitile' part is the virus sigs whereas the app (once it hits stable) shouldnt change unless it warrents a 'security' update. So, volitile should be for the data/virus sigs that need updating when new bugs hit the 'net. No, often such kind of programs need engine update. That's true for both AV and antispam programs as well. -- Francesco P. Lovergine
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 08:47:27AM +0200, Francesco Paolo Lovergine wrote: Would the kernel and X be candidates for volatile? I dont see any reason why not, if they can be marked as NotAutomatic. Due to versioned dependencies, that could be impractical for X, which has a long list of reverse depends. Sorry, with X i thought of package X instead of xserver-*. I meant for the kernel, which in some cases it could be tagged non automatic for updates, so that only the package is installed if the users wishes so. Making 2.6 kernels available for woody could have been an scenario where this approach could have work, except for the dependencies that the new kernel requires, but still is a good example of a possibility. J -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 First came darkness, then came the strangers. --Dr. Schreber (Dark City)
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote: On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: Packages like virus checkers seem to be composed of 2 parts: the app program and the data where the data in this case are virus sigs and the app is say clamav. And the 'volitile' part is the virus sigs whereas the app (once it hits stable) shouldnt change unless it warrents a 'security' update. So, volitile should be for the data/virus sigs that need updating when new bugs hit the 'net. No, often such kind of programs need engine update. That's true for both AV and antispam programs as well. -- Francesco P. Lovergine Hi Francesco, so: the program = engine part + (some un-named part) ??? and the engine part and the data part are volitile -Kev -- (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ Have you mooed today?... signature.asc Description: Digital signature
Re: about volatile.d.o/n
* Jesus Climent ([EMAIL PROTECTED]) [041009 11:10]: I meant for the kernel, which in some cases it could be tagged non automatic for updates, so that only the package is installed if the users wishes so. Making 2.6 kernels available for woody could have been an scenario where this approach could have work, except for the dependencies that the new kernel requires, but still is a good example of a possibility. Generally, new packages could be added to volatile, as long as there is a very good usage of them. However, if I see how painful security updates for the kernel currently are for the security team, I think we should better reconsider this very good - because once a package is added, we need to do security updates on it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
Re: Henning Makholm in [EMAIL PROTECTED] Some things are not so obvious: Should volatile include updates of packages such as debian-keyring? debian-policy and developers-reference? Those who need these packages will run Sid anyway. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 08:19:24PM +0200, Martin Zobel-Helas wrote: On Friday, 08 Oct 2004, you wrote: That's all for now. Comments and suggestions are welcome. i would like to see some policy, what, when and under which circumstances gets included to volatile.d.n. Is for example a package whois also a candidate for volatile? Regestries change from time to time; i just consider .org changed within the last 2,5 years... That sounds like a candidate for a stable update to me, not volatile. -- Colin Watson [EMAIL PROTECTED]
Re: about volatile.d.o/n
also sprach Colin Watson [EMAIL PROTECTED] [2004.10.09.1618 +0200]: That sounds like a candidate for a stable update to me, not volatile. You mean an r-release? The problem with those is that they have too much inertia to be able to provide fixes quickly. So then our users will have an inoperable whois for a couple of weeks at least. This is precisely the same situation as with AV scanners and precisely the motivation behind v.d.o. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: about volatile.d.o/n
This one time, at band camp, Kevin Mark said: On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote: On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: Packages like virus checkers seem to be composed of 2 parts: the app program and the data where the data in this case are virus sigs and the app is say clamav. And the 'volitile' part is the virus sigs whereas the app (once it hits stable) shouldnt change unless it warrents a 'security' update. So, volitile should be for the data/virus sigs that need updating when new bugs hit the 'net. No, often such kind of programs need engine update. That's true for both AV and antispam programs as well. Hi Francesco, so: the program = engine part + (some un-named part) ??? and the engine part and the data part are volitile In the case of clamav, most of the work of scanning is handled by library functions, and these functions are called by the frontend programs like clamscan, clamdscan, and the milter. I think that spamassassin works much the saem way - most of the real work is done by the perl module Mail::Spamassassin, and the frontend programs /usr/bin/spamassassin and spamc are an interface to using these functions. In addition to the engine itself, as has been noted, there are the data sets that the engine uses to identify potential targets. In the case of spamassassin, these are rules, and in the case of clamav, these are virus signatures. Right now, it is easy enough to get new data sets - the clamav suite inculdes an updater for it's data, and spamassassin is easy to add new rules to. The problem is updating the engine in a stable release. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpCEQgGc6Vi3.pgp Description: PGP signature
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote: This one time, at band camp, Kevin Mark said: On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote: On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: Packages like virus checkers seem to be composed of 2 parts: the app program and the data where the data in this case are virus sigs and the app is say clamav. And the 'volitile' part is the virus sigs whereas the app (once it hits stable) shouldnt change unless it warrents a 'security' update. So, volitile should be for the data/virus sigs that need updating when new bugs hit the 'net. No, often such kind of programs need engine update. That's true for both AV and antispam programs as well. Hi Francesco, so: the program = engine part + (some un-named part) ??? and the engine part and the data part are volitile snip Right now, it is easy enough to get new data sets - the clamav suite inculdes an updater for it's data, and spamassassin is easy to add new rules to. The problem is updating the engine in a stable release. Indeed, there is a consensus that data updates with the volatility of, say, virus scanner sigs belong firmly out-of-band. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 04:45:57PM -0700, Thomas Bushnell BSG wrote: Duncan Findlay [EMAIL PROTECTED] writes: When spamassassin is upgraded, it's more than just the rules. Often the method of parsing the message is changed -- leading to better results, or support for different tests is added, etc. It would be very difficult to only backport the appropriate changes, and the result would be less stable than the version from which backporting was taking place. On the other hand, each new version makes minor changes to functionality. (Ignore 3.0.0 right now, it's got different issues all together.) To require backported changes would simply be a waste of effort and would defeat the purpose to a certain extent. Nonsense. It would be harder work, and maybe there is nobody around to do the hard work. But it is hardly impossible. This is what stability is about. What you are calling for is abandoning Debian's stability judgment to upstream's, in a situation where upstream isn't making any stability promises at all. So backport the appropriate changes only, and find programmers who can do a good enough job not to screw it up and destabilize it. Thomas Thomas, The more the discussion goes on, the more value I see for this emphasis. I started with clamav in mind as my archetypal example program. But defining the class of programs, finding a form of words, is more dificult than it at first appears. Take 'useless' for example. Elsewhere in the thread person makes the point that hardware drivers could come into the 'useless' category, and I know exactly what he means: I've been there. But, I wouldn't want to have make X11 or kernels in volatile work: sounds like a world of pain. I got to thinking. In many ways the volatile conversation, is like the one which goes 'can we have a five year EOL so that oracle will support us'. Both deal with having a release cycle which is different from the status quo, and other general discussion on that subject is often heard. The appearance of volatile.d.n suggests to me that Debian is continuing to grow in a healthy way. Perhaps deepfreeze.d.n (or whatever) is waiting in the wings, or other things. I could imagine maintaining clamav against a 5 year old codebase (I do something not so different to that now). clamav is in C, and reasonably self-contained. The version skew doesn't really get to you. The perl based stuff is a bigger problem. I guess I'm saying two things: Ultimately the general rule _always_ has be 'backport the appropriate changes only'. Perhaps maintainers of candidates for volatile will want to take a cautionary second to imagine what it might be like to be working against that five-year-old codebase. And the reason I'm saying these things is that I think that volatile and main archive, 'deepfreeze-or-whatever' or whatever comes along will be at their best if they all work together, rather than being seperate little islands. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 05:13:49PM +0100, paddy wrote: Elsewhere in the thread person makes the point that hardware drivers could come into the 'useless' category, and I know exactly what he means: I've been there. And seconds after I pressed the send button I got that horrible sinking feeling. s/person/Daniel Burrows/ I'm sorry Daniel, no offense intended. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
Jesus Climent [EMAIL PROTECTED] writes: Just another thought... You think that people looking at the code to backport a given set of features has a better clue about stability than the long time experienced upstream programers? I expect the Debian maintainers of such a package to understand the code very well themselves, because that would be a necessary part of the job. The upstream maintainers might well have a good clue about stability, but the point is that they haven't promised anything about stability. Stability means not changing features and interactions with other parts of the system, and I don't think they worry about that much at all. Thomas
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote:
This one time, at band camp, Kevin Mark said:
On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote:
On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote:
Packages like virus checkers seem to be
composed of 2 parts: the app program and the data where the data in
this case are virus sigs and the app is say clamav. And the 'volitile'
part is the virus sigs whereas the app (once it hits stable) shouldnt
change unless it warrents a 'security' update. So, volitile should be
for the data/virus sigs that need updating when new bugs hit the 'net.
No, often such kind of programs need engine update. That's true for
both AV and antispam programs as well.
Hi Francesco,
so:
the program = engine part + (some un-named part) ???
and the engine part and the data part are volitile
In the case of clamav, most of the work of scanning is handled by
library functions, and these functions are called by the frontend
programs like clamscan, clamdscan, and the milter.
Hi Stephen,
so,
email
|
\/
{lib}clamav-clamav{frontend}-clamav-{data}
|
\/
mbox
the api for {lib} and {frontend} must be in sync.
update {lib} api and then you would have to update all {frontends}.
does not sound like 'stable' policy?
the data format used in {data} and read by the {lib} must be in sync.
update the {lib} may lead to a change in data format which would
probably lead to an api change which would mean updates to all
{frontends}. ugh!
would it be good to backport new dataformat to 'stable' dataformat or
risk having to fix {lib} and {frontend}s? then they would be 'unstable'
and need QA?
clam-data has an updated but not all similar frontends do.
what is done for others that do not have 'freshclam'?
what is the diff between
stable.update,security.update,volitile.update?
enquiring minds what to know? hope this is not too OT!
-Kevin
--
(__)
(oo)
/--\/
/ |||
* /\---/\
~~ ~~
Have you mooed today?...
signature.asc
Description: Digital signature
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 04:37:14PM +0100, paddy wrote: On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote: This one time, at band camp, Kevin Mark said: On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote: On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: Packages like virus checkers seem to be composed of 2 parts: the app program and the data where the data in this case are virus sigs and the app is say clamav. And the 'volitile' part is the virus sigs whereas the app (once it hits stable) shouldnt change unless it warrents a 'security' update. So, volitile should be for the data/virus sigs that need updating when new bugs hit the 'net. No, often such kind of programs need engine update. That's true for both AV and antispam programs as well. Hi Francesco, so: the program = engine part + (some un-named part) ??? and the engine part and the data part are volitile snip Right now, it is easy enough to get new data sets - the clamav suite inculdes an updater for it's data, and spamassassin is easy to add new rules to. The problem is updating the engine in a stable release. Indeed, there is a consensus that data updates with the volatility of, say, virus scanner sigs belong firmly out-of-band. Hi Paddy, so that leaves libs and frontends (at least for clamav) but I thought the ideas was to protect against virus threats? if its out-of-band (not in debian control) than the only thing that would seem reasonable is to convert between any new data format and the data format used in stable. current stable= no changes to package = stable system with security left to user with volitile=backport data format= stable system with some new data to improve security somewhat with volitile=backport lib, frontends,data?= possible unstable system with possibly up-to-data security Dont take the above as anything other than my overexagerated guess. I'm just thinking it through to see if I can squeeze this into me wee brain! -Kev -- (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ Have you mooed today?... signature.asc Description: Digital signature
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 11:44:41AM +0200, Andreas Barth wrote: Generally, new packages could be added to volatile, as long as there is a very good usage of them. However, if I see how painful security updates for the kernel currently are for the security team, I think we should better reconsider this very good - because once a package is added, we need to do security updates on it. I am not implying it has to be, but in the long run it can be a good candidate to add value to an otherwise old (yeah, stable too) distribution. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 That's thirty minutes away. I'll be there in ten. --Wolf (Pulp Fiction)
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 03:54:11PM -0400, Kevin Mark wrote: On Sat, Oct 09, 2004 at 04:37:14PM +0100, paddy wrote: On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote: This one time, at band camp, Kevin Mark said: On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote: On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: Packages like virus checkers seem to be composed of 2 parts: the app program and the data where the data in this case are virus sigs and the app is say clamav. And the 'volitile' part is the virus sigs whereas the app (once it hits stable) shouldnt change unless it warrents a 'security' update. So, volitile should be for the data/virus sigs that need updating when new bugs hit the 'net. No, often such kind of programs need engine update. That's true for both AV and antispam programs as well. Hi Francesco, so: the program = engine part + (some un-named part) ??? and the engine part and the data part are volitile snip Right now, it is easy enough to get new data sets - the clamav suite inculdes an updater for it's data, and spamassassin is easy to add new rules to. The problem is updating the engine in a stable release. Indeed, there is a consensus that data updates with the volatility of, say, virus scanner sigs belong firmly out-of-band. Hi Paddy, so that leaves libs and frontends (at least for clamav) but I thought the ideas was to protect against virus threats? if its out-of-band (not in debian control) than the only thing that would seem reasonable is to convert between any new data format and the data format used in stable. maybe there is a place for this, but my understanding is the evolution of data formats is coupled to changes in the scaning engine and backward compatibility is maintained upstream for as long as the upstream maintainers deem reasonable. It may be that engines will eventually evolve to the point where these changes happen on the timescale of a debian stable release, then again it may be in the nature of the problem that they never will. Noone seems to be suggesting that the former is on the immediate horizon (as they are for mozilla for example). I am arguing the latter. current stable= no changes to package = stable system with security left to user for clamav, i would hope security.d.o to cover as usual. and virus scanning is not generally about protecting linux hosts. So I see it as a question of function rather than security, in this case. with volitile=backport data format= stable system with some new data to improve security somewhat maybe, see above. with volitile=backport lib, frontends,data?= possible unstable system with possibly up-to-data security clamav is a really good example of a very self-contained, at least in some setups. two pipes, no privs (someone corrrect me if I'm wrong). In the case of clamav, what i believe is at issue is not the stability or security of whole individual systems (possibly the clamav function) but importantly the stability of the archive, that system. Dont take the above as anything other than my overexagerated guess. I'm just thinking it through to see if I can squeeze this into me wee brain! It's great to talk with you. The more I look at it, the more of the complexity of the problem I see. I hope you can find plenty more room in there ;) Regards, Paddy -Kev -- (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ Have you mooed today?... -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 10:48:15PM +0100, paddy wrote: maybe there is a place for this, but my understanding is the evolution of data formats is coupled to changes in the scaning engine and backward compatibility is maintained upstream for as long as the upstream maintainers deem reasonable. It occurs to me that it may be possible to do some backporting of signatures (as distinct from a simple mechanical translation). No doubt Thomas will provide encouragement, if you are inclined to undertake such a sisyphean task. Peering into my crystal ball I see a man with a soldering iron handing you a medal emblazoned with the words 'Real Programmer'. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 03:44:13PM -0400, Kevin Mark wrote:
On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote:
This one time, at band camp, Kevin Mark said:
On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote:
On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote:
Packages like virus checkers seem to be
composed of 2 parts: the app program and the data where the data in
this case are virus sigs and the app is say clamav. And the 'volitile'
part is the virus sigs whereas the app (once it hits stable) shouldnt
change unless it warrents a 'security' update. So, volitile should be
for the data/virus sigs that need updating when new bugs hit the 'net.
No, often such kind of programs need engine update. That's true for
both AV and antispam programs as well.
Hi Francesco,
so:
the program = engine part + (some un-named part) ???
and the engine part and the data part are volitile
In the case of clamav, most of the work of scanning is handled by
library functions, and these functions are called by the frontend
programs like clamscan, clamdscan, and the milter.
Hi Stephen,
so,
email
|
\/
{lib}clamav-clamav{frontend}-clamav-{data}
|
\/
mbox
Apologies Stephen, you will need to correct me, but here goes:
email
|
V
stuff
|
libs -{api.3}--{api.4}
| |
V V
sigs -{api.1}- engine -{api.2}- frontend
|
{api.4 or 5}
|
V
stuff...
the api for {lib} and {frontend} must be in sync.
update {lib} api and then you would have to update all {frontends}.
does not sound like 'stable' policy?
if {api.2} changes then presumably frontend must change.
the data format used in {data} and read by the {lib} must be in sync.
update the {lib} may lead to a change in data format which would
probably lead to an api change which would mean updates to all
{frontends}. ugh!
I imagine it is quite possible for {api.1} to change without impacting
{api.2}. Indeed, I suppose that to be part of the value of {api.2}.
If it actually exists. I confess, I made it up.
would it be good to backport new dataformat to 'stable' dataformat or
risk having to fix {lib} and {frontend}s? then they would be 'unstable'
and need QA?
see my previous mail.
clam-data has an updated but not all similar frontends do.
what is done for others that do not have 'freshclam'?
This is in flux, and part of the problem being discussed. See for
instance discussion of snort rules and oinkmaster, or nessus-plugins.
what is the diff between
stable.update,security.update,volitile.update?
enquiring minds what to know? hope this is not too OT!
Don't know, but I guess perhaps this is a question for Andi.
Regards,
Paddy
-Kevin
--
(__)
(oo)
/--\/
/ |||
* /\---/\
~~ ~~
Have you mooed today?...
no, why do you think I should ???
--
Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
Here I go, replying to myself again ... On Sat, Oct 09, 2004 at 10:48:15PM +0100, paddy wrote: clamav is a really good example of a very self-contained, at least in some setups. two pipes, no privs (someone corrrect me if I'm wrong). In the case of clamav, what i believe is at issue is not the stability or security of whole individual systems (possibly the clamav function) but importantly the stability of the archive, that system. Even if I'm not oversimplifying, I'm assuming that compromise of a clamav process could give access to any local exploits available through available system calls. I take it that stable and security.d.o pick up the tab for this. Which makes me wonder: I seem to recall that maintenance of linux kernels has tended to drop covering local holes after a period on old kernels. I take it stable has this covered, but it would be a consideration for any potential deep-freezers, and is at least a box to check for volatile. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
about volatile.d.o/n
Hi all, we had some discussion about volatile, and I'm more and more considering to pick this task up. I think some issues are quite obvious: - packages should only go in in cooperation with the maintainers; - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; - Good candidates are clamav (including spin-offs), spamassassin, chkrootkit; - It should allow any administrator to just use volatile, as they just use security.d.o, and they should be confident that nothing is broken by that; - for bugs, the normal debian bug tracking system should be used. Some things are not so obvious: - security support: There should be security support for volatile. However, security.d.o is probably not the right place for that, and adding another task to the security-team is IMHO also not the way to go. So, this needs to be placed on the burden of the volatile team. - releases of volatile: One could consider to seperate volatile into a release and a staging area. An advantage would be that system administrators would only need to update on some times. However, if we restrict volatile, only upload required changes and don't have more than 10 packages in it, we don't need that. - adding volatile packages to point releases: Though it may be seen as good idea to add volatile packages at the next point release, this is currently a no-go. I can see the good reasons for that, and I accept them. Two technical questions remain open for now, and needs to be solved independend of the policy questions above. - ftp-server: Should volatile be a normal part of the debian ftp-server, or be setup independently (like e.g. security.d.o is)? Normal part would of course be nicer for our users (and especially mirroring is free), but requires some more work initially. However, this decision is in the domain of the ftp-masters. - architectures/buildd support (partly connected with ftp-server): Which architectures should be supported? Perhaps starting with a smaller number is a good idea, and adding more if they can cope with the updates. I added http://volatile.debian.net/ to be a placeholder for the current discussions. Also, there is a archive present on http://volatile.debian.net/debian-volatile, so if maintainers want to start adding packages, they may contact me. That's all for now. Comments and suggestions are welcome. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
Andreas Barth [EMAIL PROTECTED] writes: - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; I think your proposal looks good, but I would like to see this particular item fleshed out more fully. In particular, what kinds of changes are being considered here? In other words, would it count as necessary to say new upstream major release provides a new feature which keeps the virus scanner useful, and also changes a bajillion unrelated things? In my book, the new virus definitions would be necessary, but not the bajillion unrelated things, and I would like to see a rule that you could not just put in the new upstream major release merely to get the new virus definitions. That is, some kind of minimal change to preserve utility rule, which might require the volatile-managers or whoever to be Real Programmers and not just compilers. Thomas
Re: about volatile.d.o/n
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [041008 18:25]: Andreas Barth [EMAIL PROTECTED] writes: - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; I think your proposal looks good, but I would like to see this particular item fleshed out more fully. In particular, what kinds of changes are being considered here? In other words, would it count as necessary to say new upstream major release provides a new feature which keeps the virus scanner useful, and also changes a bajillion unrelated things? In my book, the new virus definitions would be necessary, but not the bajillion unrelated things, and I would like to see a rule that you could not just put in the new upstream major release merely to get the new virus definitions. Agreed. So, this means: Backport the necessary changes. Sometimes, it's just not enough to only update the virus scanner definitions, because new functionality is needed to scan the files (just consider that a very new archive format gets so popular that it needs to be supported, just like zip now). And, if there are changes that should be available on stable, but not be the default (like e.g. the current spamassassin3), than they might get in as new package, not disturbing the users of the old one, but giving more choices. (Of course, even then, the package needs to be a bit more mature than the curent spamassassin3, but that's a different thing. ;) That is, some kind of minimal change to preserve utility rule, which might require the volatile-managers or whoever to be Real Programmers and not just compilers. Of course it requires them to be Real Programmers. The job is _not_ mechanically compiling something on stable. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
Andreas Barth [EMAIL PROTECTED] writes: Agreed. So, this means: Backport the necessary changes. Sometimes, it's just not enough to only update the virus scanner definitions, because new functionality is needed to scan the files (just consider that a very new archive format gets so popular that it needs to be supported, just like zip now). Certainly; that makes sense. Good, I'm comfortable with this if it can get written in to whatever official policy document in the right way. Thomas
Re: about volatile.d.o/n
Scripsit Andreas Barth [EMAIL PROTECTED] Some things are not so obvious: Should volatile include updates of packages such as debian-keyring? debian-policy and developers-reference? -- Henning Makholm Al lykken er i ét ord: Overvægtig!
Re: about volatile.d.o/n
This one time, at band camp, Henning Makholm said: Scripsit Andreas Barth [EMAIL PROTECTED] Some things are not so obvious: Should volatile include updates of packages such as debian-keyring? debian-policy and developers-reference? I could see (possibly) debian-keyring, but policy and the reference should be essentially frozen with the release - if policy X is in effect at release time, all packages that are targeted at that release must use policy X, unless I'm mistaken. The reference is, I suppose, less frozen, but updates that address things like new packaging procedures that are not present in stable would be problematic. Also, since these are all arch: all packages, it's not like they're a big deal to just grab if you need a newer copy for some reason. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpOj2QZ2byW4.pgp Description: PGP signature
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 06:31:56PM +0200, Andreas Barth wrote: Agreed. So, this means: Backport the necessary changes. Sometimes, it's just not enough to only update the virus scanner definitions, because new functionality is needed to scan the files (just consider that a very new archive format gets so popular that it needs to be supported, just like zip now). When spamassassin is upgraded, it's more than just the rules. Often the method of parsing the message is changed -- leading to better results, or support for different tests is added, etc. It would be very difficult to only backport the appropriate changes, and the result would be less stable than the version from which backporting was taking place. On the other hand, each new version makes minor changes to functionality. (Ignore 3.0.0 right now, it's got different issues all together.) To require backported changes would simply be a waste of effort and would defeat the purpose to a certain extent. And, if there are changes that should be available on stable, but not be the default (like e.g. the current spamassassin3), than they might get in as new package, not disturbing the users of the old one, but giving more choices. (Of course, even then, the package needs to be a bit more mature than the curent spamassassin3, but that's a different thing. ;) That is, some kind of minimal change to preserve utility rule, which might require the volatile-managers or whoever to be Real Programmers and not just compilers. Hmm.. -- Duncan Findlay signature.asc Description: Digital signature
Re: about volatile.d.o/n
Hi Andreas, On Friday, 08 Oct 2004, you wrote: That's all for now. Comments and suggestions are welcome. i would like to see some policy, what, when and under which circumstances gets included to volatile.d.n. Is for example a package whois also a candidate for volatile? Regestries change from time to time; i just consider .org changed within the last 2,5 years... Greetings Martin -- Martin Zobel-HelasPGP-Key: 0xF7AC3AF0 signature.asc Description: Digital signature
Re: about volatile.d.o/n
also sprach Martin Zobel-Helas [EMAIL PROTECTED] [2004.10.08.2019 +0200]: Is for example a package whois also a candidate for volatile? Regestries change from time to time; i just consider .org changed within the last 2,5 years... I would say that a new version of whois could be included in volatile if it becomes useless. I don't think anything should be in volatile from the start. And I certainly don't think it should be volatile.debian.*net*. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: about volatile.d.o/n
* Henning Makholm ([EMAIL PROTECTED]) [041008 19:50]: Scripsit Andreas Barth [EMAIL PROTECTED] Some things are not so obvious: Should volatile include updates of packages such as debian-keyring? debian-policy and developers-reference? Pros: Well, these updates don't break any thing. Cons: There is no need to treat them special, or do security updates. Furthermore, it's easy to get them from backports.org. Perhaps, adding some information about how easy it's to get them from there would however be a good idea. (And, of course, if someone does a developers backport collection, including keyring, developers-reference, dpatch, debhelper etc, this might also be a good collection - but this has than a different target group than volatile.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
Hi Martin, On Friday, 08 Oct 2004, you wrote: also sprach Martin Zobel-Helas [EMAIL PROTECTED] [2004.10.08.2019 +0200]: Is for example a package whois also a candidate for volatile? Regestries change from time to time; i just consider .org changed within the last 2,5 years... I would say that a new version of whois could be included in volatile if it becomes useless. I don't think anything should be in volatile from the start. whois was just an example. i agree with you to not include all packages from the begining in volatile. But we need to clarify under which conditions such a package gets added. And I certainly don't think it should be volatile.debian.*net*. agreed. Martin -- Martin Zobel-HelasPGP-Key: 0xF7AC3AF0 signature.asc Description: Digital signature
Re: about volatile.d.o/n
* Duncan Findlay ([EMAIL PROTECTED]) [041008 20:10]: On Fri, Oct 08, 2004 at 06:31:56PM +0200, Andreas Barth wrote: Agreed. So, this means: Backport the necessary changes. Sometimes, it's just not enough to only update the virus scanner definitions, because new functionality is needed to scan the files (just consider that a very new archive format gets so popular that it needs to be supported, just like zip now). When spamassassin is upgraded, it's more than just the rules. Often the method of parsing the message is changed -- leading to better results, or support for different tests is added, etc. It would be very difficult to only backport the appropriate changes, and the result would be less stable than the version from which backporting was taking place. On the other hand, each new version makes minor changes to functionality. Well, I think, it's in the end a case-by-case decision whether it's better to take more or less a current package, und perhaps weed out some definitly unrelated changes, or to take the old package and backport some changes. Of course, in the end, the goal needs to be to make the package as useable as possible - and of course, above all, do no harm, and don't break things. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* martin f krafft ([EMAIL PROTECTED]) [041008 20:30]: And I certainly don't think it should be volatile.debian.*net*. I'm open to changing this; however, for the start, it's easier with debian.net - same as planet that also came to life as planet.debian.net. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
