Re: 7.5.1 Overwriting files in other packages
* Karl M. Hegbloom [EMAIL PROTECTED] [010512 20:24]: Is this always true? 7.5.1 Overwriting files in other packages Firstly, as mentioned before, it is usually an error for a package to contain files which are on the system in another package, though currently the --force-overwrite flag is enabled by default, downgrading the error to a warning, Which part? The usually an error for a package to contain files which are on the system in another package piece, or the currently the --force-overwrite flag is enabled by default piece, or the downgrading the error to a warning piece? And, as far as I can tell, yes, it is always true that usually it is an error for two packages to contain duplicate files when both can be installed on a system. -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Bug#91257: re-proposing this
* Sam TH [EMAIL PROTECTED] [010507 00:11]: I've never seen AbiWord work over remote X if the fonts weren't installed in *both* locations. Thus, AbiWord installs on a machine without the fonts are *not useful* *at all*. Sam, please don't take offense at this: the way I see it, if program cannot function normally under circumstances that most X clients won't even notice, I tend to think program is broken. Taking Branden's proposal entirely in the abstract, it is simply codifying the way X was designed to run. Anything against this *is* a bug, because it is not keeping with the network transparency of X. However, if the AbiWord developers don't figure they will get around to fixing AbiWord any time soon, it sure would be a shame to keep AbiWord out of the distribution. Branden, would you have great compunction against making your current must a should? -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Finishing the FHS transition
* Manoj Srivastava [EMAIL PROTECTED] [010507 13:53]: field; and using the standards version field as a reason ti file bugs is just plain wrong. Is this working under the assumption that the release manager will drop all packages not recent enough when freezing? -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Special init.d scripts
* Julian Gilbey [EMAIL PROTECTED] [010507 15:44]: Most init.d scripts are expected to support all of start, stop, etc. options. But there are a small number of scripts which are obvious exceptions to this rule: restart, reboot, single, mountall.sh and so on. Julian, I'm inclined to think that unless someone is complaining about these scripts, we may as well leave well enough alone. :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Bug#91257: re-proposing this
* Anthony Towns aj@azure.humbug.org.au [010506 00:05]: Seconded, with the proviso that I reserve the right to later be disagreeable about some of the musts... AJ, I don't think anyone would ever expect you to give up being disagreeable about musts. :) Actually, we might be rather disappointed or disillusioned. :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
[retracted] sarnold's policy diff for .so files
Greetings; I am pleased that Josip's proposal has received several seconds. (Though I don't think many were signed -- I am fairly certain that they do need to be signed to count!) Since my goal is to get this thing taken care of as easily as possible, I am retracting both my policy proposals so that Josip's will have no problem being accepted, implemented, and these bugs closed once for all. :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
[PROPOSAL] Re: Shared libs vs. plugins.
* Wichert Akkerman [EMAIL PROTECTED] [010426 11:18]: Previously Daniel Kobras wrote: For now I added a lintian overrides for this, but Sean asked me to bring up discussion here to clarify what lintian should treat as shared lib in the future in order to properly solve this issue. Geez, again? Basically a .so files that is not in /lib, /usr/lib, /usr/X11R6/lib or another directory listed in /etc/ld.so.conf is not a library (the dynamic linker can't find it anyway then) . Wichert, I think Geez, again? is the incorrect response to Daniel's mail. Bugs #42399 and #65345 against debian-policy have been outstanding for 1 year and 268 days and 322 days. #65345 even has a patch against lintian, though it is likely far too old to automatically apply. Sean forwarded the bugs from lintian to debian-policy 8 months after the patch was submitted. Sadly, Sean did not give comments why he did so; however, I hope Sean will forgive me when I suggest he did so because he likely wants an amendement to policy to document the correct handling of .so files outside of the standard (and configured) paths before he changes lintian. (If he were to change it now, afaict, lintian would not be truly policy compliant.) In that vein, I have taken a stab at a policy diff. I have made the diff against the .txt version -- hopefully no one will be upset at me. Since I am not a Debian developer, I do not know if I can submit a policy proposal. If that is the case, and there are no obvious flaws in this patch, I would hope someone would kindly resubmit the proposal in their own name, so this bug could be fixed finally. :) To make things easy for anyone, lets just explicitly place this text in the public domain, so that it can be included in debian-policy without those hideous copyright issues. --- policy.txt Thu Apr 26 13:56:29 2001 +++ so-policy.txt Thu Apr 26 14:04:10 2001 @@ -2313,6 +2313,13 @@ library links point to them, just before `dpkg' continues the installation and removes the links! + It is the case that some packages supply plugins intended for + internal use only and these plugins are often shared libraries. If + the plugin files are not installed in the default search path of + `ld.so' (/lib, /usr/lib), or in common locations specified in + `/etc/ld.so.conf' (such as /usr/X11R6/lib), then the package is not + required to comply with the paragraph requiring symbolic links. + 9.1. The `shlibs' File Format - -- Earthlink: The #1 provider of unsolicited bulk email to the Internet. --- policy.txt Thu Apr 26 13:56:29 2001 +++ so-policy.txt Thu Apr 26 14:04:10 2001 @@ -2313,6 +2313,13 @@ library links point to them, just before `dpkg' continues the installation and removes the links! + It is the case that some packages supply plugins intended for + internal use only and these plugins often have an extension .so. If + the plugin files are not installed in the default search path of + `ld.so' (/lib, /usr/lib), or in common locations specified in + `/etc/ld.so.conf' (such as /usr/X11R6/lib), then the package is not + required to comply with the paragraph requiring symbolic links. + 9.1. The `shlibs' File Format - pgpl5miLScG1p.pgp Description: PGP signature
Re: [PROPOSAL] Re: Shared libs vs. plugins.
* Josip Rodin [EMAIL PROTECTED] [010426 14:54]: Our inability to get this into Policy is appaling, isn't it? : Especially since both you and Wichert have put effort into this -- that is two possible seconds for a proposal. I've taken a closer look at the policy-process text and I do not think I am actually allowed to make proposals. (Though in the section about seconding, it makes especial reference to registered Debian developers. Perhaps for the purposes of getting this bug taken care of, simply being An Interested User counts for proposals. If this is in error (Julian/Manoj?) let me know and I'll stop proposing things. :) They need to be exempt from the rule for shlibs file, too. See my attempt in #66023... Aye, too true. It may be easier for the proposal to not decide the paths involved -- it should be sufficient to say which paths are *not* allowed. Another shot (again placed in the public domain).: --- policy.txt Thu Apr 26 19:31:26 2001 +++ so-policy.txt Thu Apr 26 19:57:17 2001 @@ -2313,6 +2313,15 @@ library links point to them, just before `dpkg' continues the installation and removes the links! + It is the case that some packages supply plugins intended for + internal use only and these plugins are often technically shared + libraries. If the plugin files are not installed in the default + search path of `ld.so' (currently /lib, /usr/lib), or in common + locations specified in `/etc/ld.so.conf' (such as /usr/X11R6/lib), + then the package's plugins are not required to comply with the + paragraph requiring symbolic links nor the `shlibs' sections + following. + 9.1. The `shlibs' File Format - -- Earthlink: The #1 provider of unsolicited bulk email to the Internet. --- policy.txt Thu Apr 26 19:31:26 2001 +++ so-policy.txt Thu Apr 26 19:57:17 2001 @@ -2313,6 +2313,15 @@ library links point to them, just before `dpkg' continues the installation and removes the links! + It is the case that some packages supply plugins intended for + internal use only and these plugins are often technically shared + libraries. If the plugin files are not installed in the default + search path of `ld.so' (currently /lib, /usr/lib), or in common + locations specified in `/etc/ld.so.conf' (such as /usr/X11R6/lib), + then the package's plugins are not required to comply with the + paragraph requiring symbolic links nor the `shlibs' sections + following. + 9.1. The `shlibs' File Format - pgpDcex5ySjTp.pgp Description: PGP signature
Re: Must and should: new proposal (was: Re: Must and should again)
* Anthony Towns aj@azure.humbug.org.au [010416 05:54]: Does that possibility satisfy everyone: - MUST and SHOULD change to the universally-recognised IETF meanings It's still not clear why this would be a Good Thing. The only real reason I've seen is that it's confusing people (and then, it's not apparently confusing maintainers per se, just policy people who think about it too much). That could be solved just as well by changing must to HAVE TO and should to OUGHT TO (and may to MIGHT LIKE TO) or something. [2] I like Julian's suggestion. It isn't so much to prevent confusion as it is for convenience of not forcing a context switch when people read RFCs versus when people read policy. People manage to work with multiple definitions of words all the time -- but we could avoid forcing it, and the ensuing discussion, by switching our meanings to match the IETF's. If we can simultaneously (a) get the same meanings as the IETF and (b) make clear the distinctions between RC and our desires of how packages should act by adding a simple asterisk, I am honestly surprised you aren't so keen on it, aj. :) I figured you would be the *first* person to support Julian's suggestion; you wouldn't have to object every time someone introduced MUST to a proposal. :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Bug#92981: uw-imapd-ssl: can't use maildir format with uw-imap (fwd)
[I've gotten to the point of not knowing who said what.. so all attributions are cut.] Or better, it requires that the delivery agent runs under uid of the user that owns the mailbox. But then the delivery agent has to start off running as root to fire off an MDA with the user id of the user that owns the mailbox. Isn't it normal for an MTA to have root at that point, so that they can do use the -d option for procmail or maildrop? Well, I think it sure would be nice for the delivery phase to be handled while running as the user; if the MTA is running as roots and checks if it is allowed to write to a file as a user, it is quite probably vulnerable to a race condition: if the file is replaced by a symlink to /etc/shadow or something similar between the time of check and the time of use (TOCTTOU problems) files could be overwritten that should not be overwritten. If the MTA, running as root, drops its priveledges for the actual delivery, it certainly could be a lot more secure than an MTA that runs as root all the time, or runs sgid mail. What this has to do with the policyness (nice new word :) of qmail or other MTAs, well, I just don't know. shrug :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: .text or .txt
* Alexander Hvostov [EMAIL PROTECTED] [010412 22:47]: I'd frankly prefer some sort of strong typing mechanism on the filesystem (like in MacOS), but that wouldn't be altogether helpful here. Just a thought I had when I read this... jerk Why don't you compile a list of the worst features of all operating systems and request them as features? /jerk :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Bug#89039: Not policy's job?
Frank, I understand Debian Policy's purpose is to document what Debian considers good practice, not document the tools that may be used. Thus, I think it is perfectly acceptable for Debian Policy to defer to the update-menu documentation for the proper format of the menu files. If this bug is suggesting that the information should be available somewhere, then the menufile(5) manpage may be useful. However, if you think that Debian Policy is the correct place for the menu file syntax, please followup with reasons why Debian Policy should include it rather than let the update-menu tool's documentation describe its configuration files. (I seem to recall another bug that wanted to move documentation into policy, possibly involving mime-support, but I cannot find it now. It may be useful to discuss both simultaneously.) Thanks. :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Must and should again
* Julian Gilbey [EMAIL PROTECTED] [010412 17:03]: My suggestion is: change should to must in policy, and give packages some time to migrate (eg., one year) before starting to do NMUs. Then any packages uploaded within the coming year will have to satisfy this requirement (or have a lintian override if there's a special reason why they don't need to). I've wondered about this several times in the past. Would it be possible/feasible/desirable to have an amendment to policy that specifies a schedule for its own replacement? I am thinking something along these lines: BEGIN METAFOO Packages supporting foo should register themselves with metafoo. After 31 Dec 2001, all text between BEGIN METAFOO and END METAFOO shall be replaced with Packages supporting foo must register themselves with metafoo. END METAFOO. While I like the gist of your email (a process to specify this sort of transition on a grand scale), a hack such as this may be used to the same effect -- as long as people don't mind two different versions of policy based on the date. Comments? -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Definition of alphanumeric?
* Antti-Juhani Kaijanaho [EMAIL PROTECTED] [010402 01:32]: On 20010402T030737-0500, Manoj Srivastava wrote: So, what is the provenance of this CURDIR variable? Has it been blessed by POSIX? indeed not. I believe this is irrelevant, as portable make is next to useless. I'll admit I don't know make very well, but a cursory read-through of O'Reilly's make book did not give me this impression. Furthermore, there is no need to complicate matters worse -- if CURDIR is not portable but PWD is portable, then only nutters would suggest using CURDIR instead of PWD. (Apologies to the original poster; I figure the portability issue was unknown to him or her.) There is no need to go out of our way to make software unportable. (*sigh* Lookit me ma! Me know English good!) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
packages affected list for must changes to policy (was: Re: Bug#91257: [PROPOSED] changes to X font policy)
* Anthony Towns aj@azure.humbug.org.au [010325 01:11]: BTW, I'm inclined to think it'd be a good idea for people who want to add a must requirement (or to change a should to a must) to include a list of packages that would need to be removed from the distribution due to the change. Anyone agree/disagree? While I appreciate your desire to increase understanding of consequences of policy changes, asking every policy change author to examine the details of `apt-cache pkgnames | wc -l` packages (on my machine, 8458 packages!) is .. well, assume someone can check each package in an average of one second, that would still take nearly two and a half hours of otherwise productive time. If examining each package took a more reasonable ten seconds, that is a whole day's work spent to find which packages will need to change to stay in the distribution. Why don't you like the current system? I have thought the proposal / vote process will keep arbitrary changes out of policy, and a package maintainer is free to change bugs against his or her package to be against policy with a note stating why compliance is difficult for his or her package. If it turns out to be too difficult for a package to comply with policy, fine, re-amend policy if the package is important enough to keep despite non-compliance. Furthermore, with releases as far apart as they are, maintainers have an average of six to eight months to fix problems with their packages.[1] I would hope something could be worked out in that time frame. I don't see anything drastically wrong with the current process. Why do you disagree with it? Cheers [1]: Yes, statistically speaking, half the time between releases. Individual cases, with individual changes, could range between 16 months to less than a day, but I doubt many policy changes are going to be made in the days before a release. -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: packages affected list for must changes to policy (was: Re: Bug#91257: [PROPOSED] changes to X font policy)
* Anthony Towns aj@azure.humbug.org.au [010325 02:30]: If you're not going to bother filing the RC bugs, there's no reason not to leave it as a should. If you are going to file the RC bugs, then someone's got to figure out which packages it applies to at some point anyway. This makes sense if one assumes that the only way packages will be brought into alignment with policy is by filing bugs; it ignores debian maintainers who read the changes to policy and change their packages without having bugs filed against their packages. (If no one does this, let me know, and I'll shutup. :) It also assumes that the only person to bother filing bugs is the proposer. Don't forget that Joe Standard User gets involved in the process too (once a proposed change has been accepted). More eyes etc. There's 6720 packages in sid/i386 at the moment, btw, not 8458. Thanks for the correction. At ten seconds per package, this is still nearly nineteen hours though. Why don't you like the current system? Because people don't seem to understand the point of the must/should dichotomy. Fair enough. However, what is the purpose of 'must' if the amount of work required to put one in place is probably beyond anyone's available time? Encouraging people to list the packages which'll have RC bugs filed against them due to a proposal they're making doesn't seem particularly drastic. If the proposal is being made in response to the behavior of several packages that have irked the proposer, I think I would have to agree that those packages should be listed -- perhaps as support for the proposed policy change. :) I agree with the idea that an example list of packages affected is a Good Thing; but I am still unconvinced that every policy change involing a 'must' must involve a possibly lengthy exhaustive search through all available packages. Cheers :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Package documentation
* Brian May [EMAIL PROTECTED] [010305 22:20]: I would suggest that it would be better use of the maintainers time fixing problems. It shouldn't be that tough; note whatever the --prefix etc options are to the configure script if it has one, and make a note of this in README.Debian. For those packages without configure, well .. hopefully it still isn't difficult. :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: [PROPOSAL] cron.* scripts should be quiet
* Julian Gilbey [EMAIL PROTECTED] [010220 07:29]: Good. How about something like cron.* scripts should not produce any non-error output in general. An exception may be made if the intention of the script is to mail a status report to root. Why specifically root? I could imagine situations where a cron script may be setup to mail to some other user and yet still want to be installed through the Debian system. I'd like to suggest deleting to root. -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: [PROPOSAL] cron.* scripts should be quiet
* Arthur Korn [EMAIL PROTECTED] [010220 09:35]: So what about: cron.* scripts should not produce any non-error output in general. An exception may be made if the intention of the script is to mail a status report to the administrator. I like this, though the should not use stdout version with the same semantic change would work just as well with me. :) Though I feel that the exeption is to broad. I don't want to be mailed status reports like everything is fine from dozends of machines. In this case, I would think a wishlist bug against the package in question, asking for a simple variable/command line switch to tweak the verbosity in non-error cases would be in order; hmm. Tough call. -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: only release packages that have maintainers?
* Sean 'Shaleh' Perry [EMAIL PROTECTED] [010220 10:39]: Anyone have comments on the idea that the only packages we should release are ones that have a maintainer, not Debian QA? In taking a quick list at the packages my machine knows about, it sure appears that Debian could still be useful if all those packages were thrown out. But, I am curious why you wish to do so. Is the Debian QA team getting tired of being the QA team? Do those packages have inordinate amounts of bugs compared to other packages? -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: packages with really old standards version
* Adrian Bunk [EMAIL PROTECTED] [010220 13:52]: On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote: So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. And just out of curiosity: apt has standards version 2.4.1 That is interesting. Of course, I bet apt 0.4 will be 3.x.x when it is finally released. And more serious: If you want to force the upgrade of the standards version you must file 579 RC bugs on these packages. Logistics aside though, wouldn't it be kind of neat to have all the packages shipped with woody be standards version 3.0 or higher? (Although, maybe sarge is a better idea for this one; sarge ought to have kernel 2.4.x, and between that and having all packages be standards version 3.x, numbering sarge to 3.0 would make a certain amount of cool sense. shrug) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: suggestion
D, while I don't want to reject the idea out of hand (noting that my only affiliation with Debian is enjoying it on my own computers, and spending far too much time helping people on the mail lists) I don't see any reason for changing our current system. Perhaps if you would point out the faults of the current system, and why you think usenet will solve those faults, your suggestion may be taken more seriously. The positive points to our current system is that all information is currently located at one point: http://lists.debian.org. One can use the archives for historical research, seeing what problems have been solved recently and how, and participate in active communities. Changing to usenet would decentralize sources of information; a user would no longer know ``lists.debian.org has the answer'' -- instead, users would be reduced to trying the various usenet archives, which, despite trying, are never quite complete nor intuitive to use. Often attachments are stripped on such services. This is setting aside two of the worst problems of usenet -- not all users have easy access to usenet news, while email is ubiquitous. #2 is the horrors of spam. When on a debian-controlled server the email lists can be kept free of spam. On usenet, only moderated groups are free of spam, and being a moderator for the amount of traffic debian does in a day would quite simply be hell for the moderator. I just don't see how using a newsgroup could possibly be better than reading debian-user@lists.debian.org for typical user support. Debian is not like most distributions. It is a very close-knit group and while it may make it difficult to attract new users (I went four years running Linux before trying Debian) once a user is `converted' to the Debian way-of-doing-things, few want to go back. In my humble opinion the lists are the glue that cements the distribution into one cohesive body. * D. Stimits [EMAIL PROTECTED] [010216 17:04]: This suggestion could probably be sent to a number of different departments of Debian, but it is most likely a general policy decision on how to support your product. I am recommending to several distribution packagers that the newsgroup comp.os.linux.* could benefit from a comp.os.linux.distributions.*, among which comp.os.linux.distributions.debian would be one. This would allow reduction of support costs at the individual packagers while allowing some of the users to better aid in helping each other with problems that are specific to individual distributions. -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Frozen distribution?
* Anthony Towns aj@azure.humbug.org.au [010216 19:43]: The easiest solution that I can think of (ie, that doesn't cause difficult to detect breakage, and that doesn't involve further significant changes or too much awkwardness) is, during the freeze, to just upload major changes to experimental, and bugfix updates to unstable. Someone recently (in the last month or two?) asked ``why not use dpkg to handle the distributions?'' though I am sure it was more eloquent. And, given AJ's response in this thread, I am beginning to think that fellow had the right idea, now that we have package pools in place. [Remembering, of course, that although I am not 'in' Debian, I still think of it as a 'we' situation. Call me nuts.] Given that we now have packages located on our servers with names such as: /pub/debian/main/packagepool/a/alphapackage-3.4-5-i386.deb These names will allow us to keep several different versions of each package in the package pools. This is important. We generate several meta-packages -- lets call them debian-release-slink, debian-release-potato, debian-release-woody, debian-release-sarge, etc, as well as debian-frozen and debian-unstable. The debian-release-* meta-package will Depend or Suggest or Recommend the packages that were ``known-good'' at the time of release. debian-unstable would Depend/Suggest/Recommend on the bleeding edge packages. debian-frozen would D/S/R on the packages intended to go into the next debian-release-* package. Changing the dependencies for the various metapackages would 'upgrade' a package -- unstable's dependencies could jump large versions, while incremental bug fixes intended for debian-release-* (security patches), debian-frozen would just cause the dependies to increment small versions. This way, unstable can remain that way, and the other two have some semblence of stability. Of course, apt would need a switch (heck, it probably already has one, it does so much already :) that would allow it to upgrade/change packages only if the version number in the D/S/R of the appropriate meta-package is updated (rather than follow the information it knows about newer versions packages). Also, it would need to be modified to not require that all packages listed in the D/S/R line be installed, but if any versions of installed packages are updated, update those. I don't think these changes would be difficult. (Ah, the joys of not being the guy in charge of whatever it is I suggest be changed..) An alternate strategy is to include in each package description (in the _Packages lists) a header claiming the distribution it is intended for. Listing three versions of a package in the one file, each one tagged with Flavor: stable or Flavor: unstable or Flavor: frozen, with an apt variable to choose which of the three to install. (Global variable is probably the best idea.) This alternate strategy would also allow major version number increases in unstable, and minor version number increases in frozen and stable. The downside of course is that this list would be huge, and each user would be required to download the whole mess daily (if the user is like all the users I know :) -- some sort of diff or delta version would be splendid. Though to tell the truth, I don't know why the old system (`old' meaning `about six months ago') couldn't handle this. Completely unrelated: I think some people could go for a ``stable-unstable'' version of Debian. If the _Packages lists would include the date the package was installed (epoch time would be easiest though not very human-readable) into the archives, then apt could be configured to install only packages that have been in unstable for X days, where X is probably about 7. This way, only packages that haven't been removed in X days due to some strange error are installed. (Strange error being ``mutt linked against non-existant library'' that plagued Marco the other day; Marco quickly replaced mutt, and users running the stable-unstable version would never have noticed.) Is it possible to roll both ideas into one elegant solution that doesn't cause the apt team to want me dead? :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
[ot?] where do we go from here with nomenclature?
IIRC, woody is the last name from toy story that we haven't used yet. Does the Cabal know which movie (if any) is next? How about Chicken Run, or the Wallace and Gromit series? Or MST3K? (Just consider, ``Manos, Operating System of Fate!'' as a login banner. :) (BTW, to join the Cabal, do I actually need to be a debian maintainer?) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: native pkg versioning (was Re: Question about native packages)
* Brian May [EMAIL PROTECTED] [010205 02:39]: I disagree. Why should dpkg, for instance, which is specific to Debian come with a diff format. Ah, but dpkg isn't specific to Debian. It is licensed in such a fashion that allows its use in other projects. (Of course, anyone likely to use dpkg elsewhere is liable to take our version number as the 'upstream' version, grab the source, and repackage the thing on their own.) -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: [PROPOSAL] Allowing crypto in the main archive
* Arthur Korn [EMAIL PROTECTED] [010128 03:48]: Shure the US is getting preferential treatment. Would you ever bother to set up master in, say, Iran and have to maintain a second master even though everything could be put onto the second master in the first place? I would guess a large part of Debian's users are located in the US. Debian already accounts for a huge amount of traffic on the internet; if Debian were to move servers to another country, as sensible as it may be in terms of politics, the dent Debian would make to the international traffic of octets would be .. enormous. How many octets do Debian servers currently pass out each day, handling apt-get upgrades? (I know I account for several hundred megs every few days; I've even asked the apt team to consider using rsync or some other binary-diff method so that the 200 changed octets in the X packages don't require 10 megaoctets of downloads. The apt team was less than thrilled to hear this suggestion without a patch in hand. :) No, moving the main server to some other country would just strain the poor intercontinental links all the more, as nice a political statement as it would make. (I would be interested in hearing information of the sort, ``debian users account for x% of all internet traffic, of which y% is *not* related to pr0nography. :) -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Bug#83669: Shared libraries
* Brian May [EMAIL PROTECTED] [010126 15:32]: Please give me a real life example of why distinguishing libraries solely by their major version number is not good enough... How does this work with the glibc mess I seem to recall from about a month ago? -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: cleaning up our task packages
* Joey Hess [EMAIL PROTECTED] [001206 21:30]: Task packages are packages whose names are prefixed with `task-'. Typically they are empty metapackages that merely depend on a collection of other packages. Joey, nice work; I agree with the general gist of what you are aiming for. When I saw the list, I thought to myself, ``this doesn't buy much over selecting the packages by hand''. However, I think we can agree that many of these packages are *useful*, even if they shouldn't be shown at tasksel time; perhaps renaming the cut packages to be: meta-netscape or meta-c-programming or meta-kde-everything ... would be very handy in allowing those who like gnome to say, ``I want gnome, but I don't want to drag KDE along with it, and I don't know which packages make a good gnome system.'' I think we will see more of these users in the future, particularly as individual application suites gain more acclaim in the world. (I have friends who think Helix Code *IS* gnome, and ask me upon seeing sawfish running, ``oh, you run Helix?'' -- a meta-gnome-blinkenflashen would help friends such as this. And no, no amount of explaining has helped. :) It might help the egos of those that have put effort into the task- packages that would be cut, as well. :) -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: cleaning up our task packages
* John Galt [EMAIL PROTECTED] [001207 18:14]: distributions is the right one. Uncle Debian in his wisdom makes the choice for him and takes care of the details. Fuck Uncle Debian and the horse he rode in on if that's the case. Now John, I consider myself fairly competent; however, with three dhcp clients to choose from (an actual situation from many months ago) many folks won't know which one is *best*, as defined by ``works on the kernel as shipped''. How are end users, installing their first Debian box, supposed to know that bozo-dhcpcd hasn't been supported for many months (but is still in the distribution) but bozo-dhclient-clown is known to work on the kernel shipped by Debian, is well-supported, and runs easily. Neither package description will mention the issues. *THIS* is where the task- system will help new users -- competent or not. It allows Debian to help people choose, when they don't know what is best -- not when they are too stupid to know what is best. -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: [PROPOSAL] Full text of GPL must be included
* Thomas Bushnell, BSG [EMAIL PROTECTED] [001205 18:49]: For all I know, you're Theo de Raadt, and you're deliberately trying to drive a wedge between the FSF and Debian out of hatred for everything GPL and everything that is not OpenBSD. Naw, if you think Theo has that kind of time (or would be this subtle :) you are obviously prone to paranoid fantasies. :) And besides -- without FSF, OpenBSD would be nowhere -- they need a compiler, for crying out loud, gzip is rather nice to have, and some people seem to have a fascination for emacs. No, I don't think John Galt == Theo. :) -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: [PROPOSAL] Full text of GPL must be included
* Thomas Bushnell, BSG [EMAIL PROTECTED] [001205 19:05]: Oh, I agree it's not likely. But surely there are Theo wannabies (horror) who do have the time. I'm still in training. :- -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: [PROPOSAL] Full text of GPL must be included
* Raul Miller [EMAIL PROTECTED] [001205 20:37]: Fortunately, things aren't very severe right now. And, certainly, I think that if we could pull a solution together by the time that Woody freezes, that would indicate good faith. It might not hurt to wait for RMS to get back to us wrt what his lawyer said. -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: [PROPOSAL] Full text of GPL must be included
Ok. I have discussed this a bit with my roommate, and we have a suggestion: Make the GPL show up in ftp motd and perhaps even the web server (headers?) and mention that many packages, as indicated, are covered under the GPL. We also mention that redistribution of the packages requires giving the GPL as well (in order to cover the friend-floppy network). This would remove the whole deal from the end OS. Anyone that gets their debian packages from cheapbytes gets it through base-files. Anyone that downloads one .deb from the servers gets it through the motd or the web page, and the onus is on the end person to continue the GPL chain. Thoughts? -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: [PROPOSAL] Full text of GPL must be included
* Brian Mays [EMAIL PROTECTED] [001130 19:41]: If we're going to be so anal about interpreting the GPL, then why doesn't anyone mention the requirements for distributing the source. Actually... we have agreed to one of: accompany the programs with complete source, the three-year offer, or ``the information you received as to the offer to distribute corresponding source code''. If users don't download the source .debs, then we have agreed to hold onto the source for three years, or pass on someone else's agreement to hold onto the source for three years. Does this mean our archives can't delete source .debs for more than three years? Yes, the BSD license looks better to me every day. :- -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: New field proposed, UUID
* Joey Hess [EMAIL PROTECTED] [001129 16:17]: [...] sign a concacentation of their md5sums? [...] I don't understand how signing a uuid that is just listed in the control file and could be modified by anyone is cryptographically secure. I would like to suggest that whatever signature scheme is in the works use something stronger than md5. Problems have been found in its compression function, and its small bit-length doesn't help much either. Using SHA-1 or a hash based on the AES standard would give more cryptographic confidence. -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: New field proposed, UUID
* Reimer, Fred [EMAIL PROTECTED] [001129 17:03]: The easy answer to that is that the version should automatically get bumped for user builds much like the kernel compile # is for Linux. The maintainers, when generating an official version, can specify the exact version when they compile the package, but it should automatically increment for user builds. Possibly not the main version number, but a sub-version number or equivalent. [Much snipped because it was getting awful ugly.] It would seem to me that a user downloading and compiling a package from source already has decided to worry about whatever is involved. If this means the user cannot simply run `foo command package' to see if theirs matches a signed copy, isn't that their own fault? (Some would say `decision', perhaps. :) Why bend over backwards to support folks who compile their own packages locally without taking the simple step of changing the package identifier, as we all already do for our kernels? Curiously yours, -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: [PROPOSAL] Full text of GPL must be included
* Rando Christensen [EMAIL PROTECTED] [001129 21:27]: What I would most like to see myself is adding a /etc/licensing/ directory in which every license used on the system can esist, for example: /etc/licensing/ \-- GPL \-- BSD \-- Other $ cd /usr/share/common-licenses $ ls -l total 88 -rw-r--r--1 root root 6111 Dec 15 1996 Artistic -rw-r--r--1 root root 1499 Aug 26 1999 BSD -rw-r--r--1 root root17992 Sep 16 1999 GPL lrwxrwxrwx1 root root8 Nov 12 19:12 LGPL - LGPL-2.1 -rw-r--r--1 root root25284 Feb 2 2000 LGPL-2 -rw-r--r--1 root root26532 Jul 7 1999 LGPL-2.1 Perhaps you could file wishlist bugreports against base-files if you wish this directory moved, or new licenses added to it (such as the X license, mpl, scsl(sp?), qt, etc..). -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Bug#77404: Proposed: task-secure-system package
* Bernd Eckenfels [EMAIL PROTECTED] [001119 15:08]: So dou u want to make the task-secure-system package conflict with telnet-server? Since we also have secure telnet severs (telnetd-ssl). So the problem is we want to make sure that task-secure-system also removes insecure packages (at least suggests you too) but does not block the sysadmin who knows what he is doing, right? Bernd, what I would think a task-secure-system might want to do instead is send daily emails to root about every package on the system that isn't specifically listed in files such as /etc/task-secure-system-secure-packages and /etc/task-secure-system-exempt-packages. (-secure-packages installed by task-secure-system, -exempt-packages installed and mofified by root because root gets tired of getting emails about packages regularly.) (I don't know what sort of comment we are making if we claim a package to be secure -- that might be more than we wish to call the individual packages. :) -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: doc-section madness
Greetings Daniele, [I have cc'd you, since I do not know if you are subscribed to -policy] * Daniele Cruciani [EMAIL PROTECTED] [001110 06:37]: I think this is the right place for asking change on policy about doc-base registering of package. Sadly, I'm not sure what you are proposing can realistically be accomplished in an organization such as Debian. (BTW, just for kicks, take a look at OpenBSD's manual pages. Perhaps such quality is shared amongst all the BSDs; I've only used OpenBSD.) The major differences between OpenBSD and Debian is that OpenBSD (and the other BSDs) is the origin of the programs. We take software from wherever we can. They write/modify theirs as they see fit, and can therefore make all the documentation fit in one place. I think we also have a lot more software readily available than the BSDs, though there is a much more clear distinction between 'core OS' and 'add-ons' in those circles... Debian, on the other hand, has many old pieces of software with manual pages, GNU software with a philosophical bent against manpages (they use info instead), and software from authors that either write their own documentation software (eg, enlightenment's dox), or distribute html/postscript/tex documentation. There once was (still is?) the ability to install some programs on debian that would turn http://localhost/doc/ or something similar into a way of reading many of the sources of info at once -- man, info, html, what is distributed in /usr/[share/]doc. Take a look at doc-central. All in all, the various authors distribute docs how they feel, and until someone cares enough (you? :) to merge all of the information into one place, it just won't get done. (Point of proof -- on my machine with roughly 500 packages installed (good god that is a lot of packages :) there are roughly 350 manpages installed that point to the undocumented manpage. Even though our policy currently requires manpages of programs in packages, maintainers just end up using the undocumented page to make users/lintian be quiet.) It would seem to me that the only method of making it happen is to care enough about it to do it yourself. -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: All services that require a restart from libc6 upgrade...
* [EMAIL PROTECTED] [EMAIL PROTECTED] [001029 18:54]: Maybe some upgrades should just be labelled reboot recommended? It will be a sad day when this happens. :( I think it is a strong selling point when I tell my MS friends, tired of rebooting after installing a new web browser, that one can run a Debian system for years without rebooting -- unless one wants a new kernel. -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: RFC: allow output from maintainer scripts
* Joey Hess [EMAIL PROTECTED] [001024 15:23]: Policy explictly says you should NOT output things to stave off boredom on the part of a user. Displaying stuff for tasks that may be slow on my 386 clearly falls under that. Hmm; I myself like twizzle sticks (ala fsck) to let one know the machine isn't spinning into oblivion... -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: Priorities
* Anthony Towns aj@azure.humbug.org.au [001009 21:10]: Well, which of emacs or vi should be the preferred editor? This is missing the biggest question of all -- which of the various Vi clones should be THE vi Debian suggests? Vim, of course. :)
.desktop files in kde2
Greetings all; For today's apt-get upgrade, I had to answer the ``replace conffile'' question many times for the kde2 packages' .*desktop files. I don't recall changing any of the .desktop files, so it would have been nice if it just replaced them all on their own. However, I think a setup similar to the debian menu system would sure be nice --- the defaults are in /usr/share/someplace and if the local admin wants to override them, they should be put into /etc/something/else. Is -policy the right place to start? It seemed all the KDE games packages do this, so I am not too sure where to go. (Upstream?) Thanks :)
Re: Preparing Debian for using capabilities: file ownership.
* Joey Hess [EMAIL PROTECTED] [000926 14:52]: Nicolás Lichtmaier wrote: Your point is so obvious. duh... how did I miss that? Of course that cracking bin would be like cracking root...! This is not an issue if a) bin has no passowrd so people cannot log in as bin and b) nothing on the system is suid bin Joey, if bin owns ls, then someone that cracks the bin account (via some non-interactive means) could replace ls with a version of ls that opens a port connected to a shell. The next time root runs ls, there is a shell running as root sitting open, ready for someone to connect with netcat. So, cracking whatever account owns the system binaries is tantamount to cracking root, whenever root executes one of those programs. Right?
