Re: RFD: Essential packages, /, and /usr
Richard Braakman wrote: The irony is that the only reason to use which is to accomodate speed freaks who want to be able to use non-bash shells. Now they get hit Or wackos who code using tcsh. :) (yes, i know about the csh programming considered harmful. I guess I'll just use perl instead.) -- Scott Dier [EMAIL PROTECTED] http://www.ringworld.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint Adams wrote: experiences problems due to their choice of /bin/sh should be ridiculed by histrionic demagogues until they can display a modicum of common sense by writing a /bin/sensible-sh wrapper that attempts to find the most suitable shell for the job. Perhaps Manoj was wrong, you shouldn't be a lawyer, but a fiction writer. -- Scott Dier [EMAIL PROTECTED] http://www.ringworld.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re:Embedded platforms was: RFD: Essential packages, /, and /usr
Manoj Srivastava wrote: Actually, adding to the utility set could be an issue, especially for low memory (ipaq/Zaurus, anyone?) or embedded systems. Since embedded systems are most likely going to use dpkg or something dpkg-like in strange ways (not installing all files), theres going to have to be much possible work on assumptions on embedded platforms. I could see it going the way of Familiar, where you install ncurses and dont end up with libpanel! This isn't directly related to the current conversation, but if embedded platforms do end up with the features to be able to exclude files there must be some sort of policy to avoid broken dependencies on theese platforms. Those platforms could be even *worse* than this debacle. Hopefully such people convince maintainers to split such packages up instead of some horribly moronoic file dependency system. If theres one thing I /HATE/ about rpm is file deps. Not me personally. I looked at the size (~19kB), and the feature set, and I saw can see scenarios in which a small network aware tool would be helpful in diagnosis (low probability ones, Or recovery from non-local tape dumps. -- Scott Dier [EMAIL PROTECTED] http://www.ringworld.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FHS vagueness on /opt
* Manoj Srivastava [EMAIL PROTECTED] [020117 16:16]: It does seem to say quite uncategorically that packages may NOT place files in /opt (the local sysadmin may do as they please). Agreed, we allready use this filesystem space and I would be happy to ignore packages that do anything to this namespace. -- Scott Dier [EMAIL PROTECTED] http://www.ringworld.org/ the desire for space travel is a metaphor for escape
Re: Should debian policy require to use debconf for postinst scripts?
* Adrian Bunk [EMAIL PROTECTED] [011206 03:29]: I will support a proposal that every interaction with the user a package makes with the user during installation must be done using debconf. But this is a post-woody thing. I also am willing to fight and scream for something like this post-woody. -- Scott Dier [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ringworld.org/ [EMAIL PROTECTED] So I ran up to him, and the exchange went something like this: Me: Oh my god! You're Larry Niven! Him: Oh my god! You're Wil Wheaton! -Wil Wheaton, in a Slashdot interview
Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable text
* Branden Robinson [EMAIL PROTECTED] [011202 02:23]: On Sat, Dec 01, 2001 at 11:14:37PM -0800, Thomas Bushnell, BSG wrote: Branden Robinson [EMAIL PROTECTED] writes: If it's not *Software* then either, 1) We must treat it as such, or; 2) We have no mandate to deal with it at all. We don't need a mandate. The US Congress is (theoretically) limited to the enumerated powers given in the US Constitution, but that's a unique case. Rather than having a gigantic footnote to the Social Contract that defines software -- a definition with which many people are certain to disagree -- we can sidestep the issue by treating everything that is submitted to Debian as Software, and reserving ourselves to making a determination as to whether or not it is Free. I agree, much of what Debian Maintainers package for its Users is not Software, but Copyrighted Licensed works. Perhaps the DFSG isn't the right name for it, since the awareness of licensed documenation is higher these days. Perhaps call it the DFLG, Debian Free Licensing Guidelines, where as the License is the focus, and not the contents. Pehraps lots of docs in main will be affected, but do we want to deticate space and bandwidth to non-free licensing, or does the cabal of publishing ideas limit us to thinking of documentation as Free? -- Scott Dier [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ringworld.org/ [EMAIL PROTECTED] So I ran up to him, and the exchange went something like this: Me: Oh my god! You're Larry Niven! Him: Oh my god! You're Wil Wheaton! -Wil Wheaton, in a Slashdot interview
Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable text
* Branden Robinson [EMAIL PROTECTED] [011202 02:53]: but do we want to deticate space and bandwidth to non-free licensing, or does the cabal of publishing ideas limit us to thinking of documentation as Free? I'm sorry, I don't understand this part. Theres been business models made out of documentation and writings not being Free, however the software around it being so. (O'Reilly, for instance) Until recently, the FDL and sorts havent overly challenged publishers to really give out any documentation electronically for free, with good reason that it makes people money. Some Writers now want to be able to write good documentation for something but have the documentation be Free in any form. This freaks out publishers, because they might not get all the possible revenue on a item, but it helps Users because they should expect better access to Good Documentation, thus hopefully freeing up thinking minds from helping users due to Bad Documentation. But thats probally not totally germane to this discussion. In any case, the people who worry about money (publishers) are worried about Free Documentation. Perhaps Debian, as a project, can help by making sure that the documentation isn't restricted horribly. By having documentation that cant be maintained in the future is somewhat worthless 'eventually' to Users, and with the Maintainers and Upstream with hands tied, having to reproduce documentation thats Free to stay Current is also a waste of time. So, the idea is that you either have non-free docs that dont go electronic, or you have Free docs that are maintainable and highly available with people buying the book because they want to either support the author or have a nice bound typeset version. -- Scott Dier [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ringworld.org/ [EMAIL PROTECTED] So I ran up to him, and the exchange went something like this: Me: Oh my god! You're Larry Niven! Him: Oh my god! You're Wil Wheaton! -Wil Wheaton, in a Slashdot interview
Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable text
welcome feedback on this proposal, but please read the archives of debian-legal as referenced above before responding. A great deal of ground has already been covered, particularly in discussions with Richard Stallman of the Free Software Foundation. -- G. Branden Robinson|Damnit, we're all going to die; Debian GNU/Linux |let's die doing something *useful*! [EMAIL PROTECTED] |-- Hal Clement, on comments that http://people.debian.org/~branden/ | space exploration is dangerous -- Scott Dier [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ringworld.org/ [EMAIL PROTECTED] So I ran up to him, and the exchange went something like this: Me: Oh my god! You're Larry Niven! Him: Oh my god! You're Wil Wheaton! -Wil Wheaton, in a Slashdot interview pgp71pOHrqE6W.pgp Description: PGP signature
Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable text
* Thomas Bushnell, BSG [EMAIL PROTECTED] [011202 14:21]: So the BTS, the mailing lists, the apparatus of the Debian Constitution, the logo, and all that is now to be excluded? Come on, We distribute the BTS and the lists in the distribution? We might distribute the 'code' behind it. But I didn't think we were packaging the current contents. Of course, the constitution is in the archive, but I dont think that prevents anyone from mangling it and giving it out. It isn't a constitution that *we* as a project will acknowledge as ours. Get your context straight. -- Scott Dier [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ringworld.org/ [EMAIL PROTECTED] So I ran up to him, and the exchange went something like this: Me: Oh my god! You're Larry Niven! Him: Oh my god! You're Wil Wheaton! -Wil Wheaton, in a Slashdot interview
Bug#111839: PROPOSAL]: packages should be cross buildable
* David Kimdon [EMAIL PROTECTED] [010910 01:38]: This patch basically says that packages should support cross-compilation. Many packages can already be cross compiled so Perhaps to the base package, but for all Optional packages to be given this burden is pretty non-trival in some packages. I think wishlist bugs against the packages that people are worried about in optional is ok, but to make it policy against all packages as a 'wishlist' bug-like-statement isn't cool. -- Scott Dier [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ringworld.org/ [EMAIL PROTECTED]
debconf dilemma
I dont know if this issue has been talked about in great detail, but I think more than just one or two people have the problem and perhaps a best practices needs to be set. The tutorial documentation doesn't seem to cover this in much detail - The problem --- Inconsistent amounts of information are reaching users through information given by debconf. Some developers have delt with this by including some information but not others, or by including no information at all. Case Study -- 'lilo' on the Open Projects Network came into #debian-devel puzzled as to which X server he was running, and if it was even a 4.x version. Later, it was figred out that he didn't choose the correct XFree86 server in the debconf questions provided. He didn't know that the xserver-xfree86 server is a 4.x server, and that the rest of the xserver-* servers are 3.x servers. This led to user disconnect as to which server to pick for his card and he chose the 3.x server that matched his card instead of the 4.x server, which he would have chose with the proper knowledge. I tried to convince the packages maintainer to include information as to help users to make an informed decision of this option, and he refused to on the grounds that the information should be in the release notes instead. However, after a user chooses a server they see a large statement on how the paths to configuration files for 4.x servers differ from 3.x servers. Elements A possibly common user error could be helped by inserting information into a debconf information dialog before a long list of choices or it could be included in documentation. However, another possibly common issue is allready included in that packages debconf template. The maintainer has also been asked not to add more chatter into the debconf interaction, while others ask for more information to beable to make decisions on questions such as the above. One Possible Solution - Remove most informational displays from debconf that aren't relating to critical or grave issues. Put other information in either the README.Debian or other documentation, such as the release notes. Is this something that should be discussed before debconf is littered with too much information that should really have been kept in documentation? Or should debconf be expanded into a tool to notify users of anything about what they are just about to choose/do? Thanks for any input. -- Scott Dier [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ringworld.org/ [EMAIL PROTECTED] pgp5u6iTnYS9S.pgp Description: PGP signature
Re: debconf dilemma
Is this something that should be discussed before debconf is littered with too much information that should really have been kept in documentation? Or should debconf be expanded into a tool to notify users of anything about what they are just about to choose/do? Also, does by including the amount of information in debconf right now cause our users to trust too much into that information. Instead let the users explicitly know that X types of information will be in informational debconf interactions, while Y types of information will be in README.Debian or the release notes. (not per package, but as a all encompassing thing.) -- Scott Dier [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ringworld.org/ [EMAIL PROTECTED]
Re: debconf dilemma
* Marcelo E. Magallon [EMAIL PROTECTED] [010902 04:27]: Basically, making the user select an X server is the wrong approach, but debconf allows for an interesting possibility, namely, another tool The input itself is great to hear, but is there a greater consensous for issues beyond the XFree86 package? I really was trying to not make this a 'rip on the maintainer' fest. (Not that its become that yet, but too much stuff directed at him becomes that.. :| ) I also found an identical problem in libpaperg, its first option is a3 from alphabetical order, whereas either [a4|letter] would be better 'at the top' options. -- Scott Dier [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ringworld.org/ [EMAIL PROTECTED]
