Re: Crazy idea: removing version numbers from debian
[EMAIL PROTECTED] (Vincent L. Mulhollon) writes: > Perhaps any package can live in unstable, but any package that has a > release critical bug older than 1 week is zapped from stable and placed back > in unstable. Upon next package upload, it will be reinstated into stable. Ack! Can you imagine what would happen under that system with a package whose bugs are not handled that quickly? The version in stable would be $foo, next week it's $foo.1, a week later it's $foo again because of a RC bug filed in week 1, another week passes and the bug is fixed, so it's $foo.1 again. Not to mention we'd have to start supporting downgrades as well as upgrades (although I'm a new developer, I'm fairly sure we don't do that). > New packages would not be allowed into stable until x days had passed in > unstable status without a Release Critical Bug. Then someone files one when the maintainer's on vacation, nobody has time to do a NMU, and it pops back into unstable. Ick. > Or perhaps any package can live in unstable, and every package has a copy of > itself in unstable, but on the last day of the month it is kicked out of > stable if it has an open RCB. If you are picky about RCBs, only apt-get > stable on the first of the month. What if a RC bug is filed the day before the deadline? Last day of the month hits, users apt-get dist-upgrade and then are faced with having to downgrade their software. > If you need a buggy package anyway, get it out of unstable. Better yet, don't put packages into stable until we release. "Stable" has a fairly well-defined meaning; I don't see much benefit from changing it. > In theory this would complicate support because there would be so many > "versions" of debian, yet developers survive with "daily" versions... But because those "daily" versions are numbered, we know that the version we're getting is the latest (or not, as we choose). How do you tell somebody "I know that was fixed in the version I uploaded last week; don't download today's though, as it's known buggy" without using version numbers? You could use dates, but that can get hideously complicated very quickly. > Finally the idea I like the best is no numbers, only named updates. See above. Numbers make a lot of things easier. > And we'd have a goal for the name. Like the goal for "whiskey" release > would be every package that needs it supports debconf, or the goal for > "vodka" is every package supports kernel 2.4 and IPv6, or the goal for > "scotch" is every package supports perl 5.6 or whatever. A great idea. But can't we do that now? -=Eric -- Any philosophy that can be put in a nutshell belongs there. -- Sydney J. Harris
Bug#194961: ITP: yaz -- A C/C++ toolkit for Z39.50/ISO23950 applications
Package: wnpp Version: unavailable; reported 2003-05-27 Severity: wishlist * Package name: yaz Version : 2.0.2 Upstream Author : IndexData * URL : http://www.indexdata.dk/yaz/ * License : BSD-ish: http://www.indexdata.dk/yaz/doc/license.php Description : A C/C++ toolkit for Z39.50/ISO23950 applications YAZ is a C/C++ programmer's toolkit supporting the development of Z39.50v3/SRW clients and servers. Sample clients and servers are included with the distribution, as well as documentation. I've put prospective packages up at http://people.debian.org/~emschwar/yaz.html if anybody cares to take a look. The license is basically BSD; it lacks clause 2 in /usr/share/common-licenses/BSD, and the disclaimer is worded slightly differently but AFAICT it is functionally identical. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux wormtongue 2.4.20skif #1 Tue Feb 18 17:27:36 MST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: Bug#197907: ITP: quark -- an audio player, for geeks, by geeks.
On Thursday, Jun 19, 2003, at 00:30 America/Denver, Sven Luther wrote: I have almost a ready package, i just now need a fine short description. How about: simple audio player with detachable GUI It's not perfect, I know. This sounds pretty nifty, actually, but hard to categorize. But this still doesn't sound quite right, and doesn't mention the second advantage, which is a bit difficult to express in a simple phrase anyway. The other thing to remember is that the short description is just a hook. It doesn't have to mention every distinguishing feature of the package, or else xemacs would never have been uploaded. :) Just attempt something catchy (which my contribution isn't, really), and leave the full description for the appropriate section. -=Eric (xemacs user, BTW)
Re: Should MUA only Recommend mail-transfer-agent?
On Thursday, Aug 7, 2003, at 02:51 America/Denver, Peter Mathiasson wrote: On Wed, Aug 06, 2003 at 10:34:28PM -0700, Steve Lamb wrote: Here it isn't. That is because that correspondence is done on company time using company equipment supposedly for company purposes. They have the right to keep records of what is going on and some companies do, indeed, keep records. Obviously they're not going to keep the spam. The point is though that they do keep records and unless your personal mail is caught by some automatic filter or is removed manually (in which case it is read anyway) it can be saved. Then perhaps you should use an encrypted tunnel to a safer location. That was, in fact, more or less what he was talking about. (Steve did not mention an encrypted tunnel, but did talk about sending personal mail through a different server than the work one). I wouldn't send mails through that channel, even if it was work related. It can look fairly unprofessional if email from your work address goes through a different server; I would be surprised and more than a little wary if email from a major vendor came through a comcast.net SMTP server. Besides, many US firms have legally mandated document retention policies; archiving sent mail may be a required part of that. Of course, most of the time it's probably not. You should value your integrity more than that. Which is why he wants to send personal mail through a non-work server, no? -=Eric
Re: status of Progeny projects
On Tuesday, Nov 11, 2003, at 23:39 America/Denver, Peter Zoeller wrote: Most software installs fail as a result of missing libraries. I would like to see a central repository for all libraries, old, new and development. A repository that when a library dependancy needs to be satisfied, the installer be it RPM, APT or anyone elses, can automatically access and download the appropriate version of library required. This repository should only hold nothing but libraries, no software, no packages, just libraries with a searchable capability that one could also manually search and download ones needs. Just curious... have you ever actually used Debian? When you write to a list comprised of Debian developers that concentrates on Debian software and library packaging needs to suggest something we've been doing that for years now, I have to wonder why. If you want to install software from Debian, all of our package installation methods automatically install all the libraries (and, optionally, any other recommended or suggested software) required for full operation. That's what we do. I'm not sure of the point of your suggestion-- having used more Red Hat systems in the past year than bears thinking about, I can see how you might think it useful for them, but even in that case, you have different libc versions, compiler revs, architectures and sometimes even kernels to keep track of, not to mention the version numbers of the libraries. The only sensible solution is to package libraries as part of a distribution, in which case I fail to see the utility of your idea. With the version numbers used in linux there is no fear as there is in the other OS of overlaying and existing library that would result in the breaking of other software. It would be no problem to run the same library beside its earlier parent satisfying the need of all software. Unless the new library was binary-incompatible with the old, requiring new revs of all the programs it uses. And then maybe the new library calls executables that don't exist, requiring you to install new software packages to handle that. At this point, it sounds like we're back to packaging libraries as part of a complete distribution, in which case I'm afraid your 'library-only' archive will not be of much use. Along with this there should be a tool that will allow the cleaning up of ones libraries based on lack of activity so that the directories holding libraries such as /lib can be safely maintained and kept from growing out of hand. Hrm. Sounds a lot like dpkg, combined with deborphan. Thanks to all open source developers for the work that has and continues to be done. You're welcome. :) -=Eric
Re: Hardware Compatibility List for Woody (exist)?
How can I collect an up-to-date Hardware Compatibility List by inspecting (which) Kernel-Code(-Parts)? (How are the SuSE people for example do this-they have a very big HCL but I don't know if Debian can use the same HCL-?) Nor, nor could they really-- SuSE generates their list by people paying them money to say their hardware is certified under SuSE Linux. Debian has no such entity for people to pay us, and we're not as a rule very interested in doing so. Furthermore, distributions like SuSE and Red Hat not only heavily patch the kernels they release, they also rely on their customers not generating a custom kernel; it's my impression that Debian users, as a rule, are much more likely to do so. If someone can answer this question I will start working on this so there will some up-to-date HCL for Woody. First you'll have to define what you mean by HCL. What goes on the list? Is it sufficient for a network card to respond to ifup, or should it perform within some epsilon of its rated speed? What about a SCSI card? Should it be measured to work with disks, scanners, tape drives, and ghod knows what else? Some driver/hardware bugs show up only after a hundred hours or so of continuous operation; how long should a device be tested until it's considered 'compatible'? How do you maintain the list? What kinds of changes would require a recertification, and what kinds wouldn't? That's not to say this isn't a useful or interesting question to ask; just make sure you realize what you're getting yourself into when you do. -=Eric
Re: plagiarism of reiserfs by Debian
I say "it ought to be obvious", because Hans put the message in there intending it to be prominent, rather than (say) putting it in a doc file. It is reasonable to assume that he cared about putting this message in front of everyone who used it. If you can't understand why removing it would annoy him then I really doubt your ability to cooperate with other people. You have to realize, we still don't know that you're correct about what he's upset about, becuase Hans has not yet come out and said exactly what the problem is. One early message he posted in this thread indicated to me that his real problem was the lack of the author list in the Debian package of reiserfsprogs. And in any event, I don't think debian-devel is the place for him to air his concerns. Except in extreme cases, we don't overrule a package maintainer's decision to package the software he maintains however he likes. I don't see any indication he has tried unsuccessfully to air his concerns with the maintainer, either via private email, or by filing a bug, so regardless of our opinons, I don't see that at this point, any of us can do much more than generate more material for a flamewar. I have sent Hans private email, suggesting that he try to work this out off-list before resorting to what appeared to me to be a rather vitriolic email as a first approach to the project as a whole. I don't see that any of the discussion that is going on at this point is going to affect in any way the contents of the reiserfsprogs package, and certainly not in a way that Hans would like. Consider: you don't know what Hans doesn't like. You don't know how he'd like things to change. You don't know what he'd consider acceptable, or not. Nor do any of us, because he still hasn't said. As a result, about all we can do as a project is comment on whether or not what the maintainer did is allowable, and it appears that removing the message from mkreiserfs is, but deleting the contributors list isn't (though that appears to be unintentional). We can, as individual members, comment on how we feel about what happened, but given that we don't know exactly what Hans is upset about, even that is perhaps a bit presumptuous. I suggest we try to give this a rest until Hans can come up with a clear statement of what's wrong, and preferably one that includes his attempts to resolve things privately and the results thereof, before we generate too much more flameage. Once we know what the actual problem is, we can consider what solutions might exist. As it is, I don't see how we can do anything but fuel the flames. -=Eric
