Bug#741304: add FHS exception for arch-indep in /usr/lib
Michael Biebl wrote: On Mon, Mar 10, 2014 at 06:39:20PM -0400, Joey Hess wrote: The FHS requirement that architecture-independent application-specific static files be located in /usr/share is relaxed to a suggestion. In particular, a subdirectory of /usr/lib may be used by a package (or a collection of packages) to hold a mixture of architecture-independent and architecture-dependent files. However, when a directory is entirely composed of architecture-independent files, it should be located in /usr/share. There are various packages which ship only architecture-independent files in /usr/lib/foo directories. One example is [0]. What's the rationale to explicitly make a distinction between directories holding only architecture-independent files and ones consisting of a mixture? Since [0] would violate this should rule, what would that mean in practice: still a bug, though non-RC severity (normal?)? I intentionally worded the proposal to downgrade this kind of case from a currently pseudo-RC bug to a normal severity bug. It's still a bug under the proposal, because it diverges from the FHS. But in this specific case, /usr/lib/dir is an interface of the program, used by other software, and it would be more painful to change it in Debian to strictly comply with the FHS than it's worth. The nice thing about non-rc severity bug reports is they can be forwarded upstream without undue urgency. IMHO this is more likely to yeild constructive results than the current state where we have some vast number of unreported RC bugs that have to be treated with high urgency, but only when someone is unkind enough to point out they exist.. -- see shy jo signature.asc Description: Digital signature
Bug#628515: recommending verbose build logs
Johnathan raises important concerns in http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;bug=628515 These have never been addressed by any proponents of verbose build logs AFAIK. I raise similar concerns in #680686. There is also discussion there of making dpkg-buildpackage produce a smart display for interactive builds (fleeting display of verbose messages with warnings separated out and highlighted) while logging the full verbose build. The dpkg maintainers have not indicated if they are willing to add that to dpkg-buildpackage. Also, there seems to be no consensus about what verbose means. Many build systems have multiple levels of verbosity. The closest this proposal comes to guidance about what level of verbosity is desired is to say we want compiler and linker command lines. (Personally, I do *not* want this output to my screen every build. '/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' '-o' 'dist/build/git-annex/git-annex' 'dist/build/git-annex/git-annex-tmp/Test.o' 'dist/build/git-annex/git-annex-tmp/CmdLine.o' 'dist/build/git-annex/git-annex-tmp/CmdLine/GitAnnex.o' 'dist/build/git-annex/git-annex-tmp/CmdLine/GitAnnexShell.o' 'dist/build/git-annex/git-annex-tmp/Main.o' 'dist/build/git-annex/git-annex-tmp/Config.o' 'dist/build/git-annex/git-annex-tmp/Common.o' 'dist/build/git-annex/git-annex-tmp/Utility/SafeCommand.o' 'dist/build/git-annex/git-annex-tmp/Annex.o' 'dist/build/git-annex/git-annex-tmp/Annex/UUID.o' 'dist/build/git-annex/git-annex-tmp/Backend.o' 'dist/build/git-annex/git-annex-tmp/Git.o' 'dist/build/git-annex/git-annex-tmp/Git/CurrentRepo.o' 'dist/build/git-annex/git-annex-tmp/Git/Filename.o' 'dist/build/git-annex/git-annex-tmp/Types.o' 'dist/build/git-annex/git-annex-tmp/Git/Types.o' 'dist/build/git-annex/git-annex-tmp/Locations.o' 'dist/build/git-annex/git-annex-tmp/Types/KeySource.o' 'dist/build/git-annex/git-annex-tmp/Types/Backend.o' 'dist/build/git-annex/git-annex-tmp/Types/TrustLevel.o' 'dist/build/git-annex/git-annex-tmp/Logs.o' 'dist/build/git-annex/git-annex-tmp/Logs/UUIDBased.o' 'dist/build/git-annex/git-annex-tmp/Logs/Trust.o' 'dist/build/git-annex/git-annex-tmp/Remote.o' 'dist/build/git-annex/git-annex-tmp/Logs/Remote.o' 'dist/build/git-annex/git-annex-tmp/Logs/Unused.o' 'dist/build/git-annex/git-annex-tmp/Logs/Transfer.o' 'dist/build/git-annex/git-annex-tmp/Logs/Presence.o' 'dist/build/git-annex/git-annex-tmp/Types/Key.o' 'dist/build/git-annex/git-annex-tmp/Messages.o' 'dist/build/git-annex/git-annex-tmp/Types/Messages.o' 'dist/build/git-annex/git-annex-tmp/Config/Cost.o' 'dist/build/git-annex/git-annex-tmp/Crypto.o' 'dist/build/git-annex/git-annex-tmp/Annex/Init.o' 'dist/build/git-annex/git-annex-tmp/Annex/CatFile.o' 'dist/build/git-annex/git-annex-tmp/Utility/Path.o' 'dist/build/git-annex/git-annex-tmp/Utility/FileMode.o' 'dist/build/git-annex/git-annex-tmp/Build/SysConfig.o' 'dist/build/git-annex/git-annex-tmp/Utility/Format.o' 'dist/build/git-annex/git-annex-tmp/Utility/Verifiable.o' 'dist/build/git-annex/git-annex-tmp/Utility/Process.o' 'dist/build/git-annex/git-annex-tmp/Utility/Misc.o' 'dist/build/git-annex/git-annex-tmp/Utility/InodeCache.o' 'dist/build/git-annex/git-annex-tmp/Utility/Env.o' 'dist/build/git-annex/git-annex-tmp/Utility/Matcher.o' 'dist/build/git-annex/git-annex-tmp/Utility/Exception.o' 'dist/build/git-annex/git-annex-tmp/Utility/Hash.o' 'dist/build/git-annex/git-annex-tmp/Utility/Scheduled.o' 'dist/build/git-annex/git-annex-tmp/Utility/HumanTime.o' 'dist/build/git-annex/git-annex-tmp/Utility/ThreadScheduler.o' 'dist/build/git-annex/git-annex-tmp/Remote/Helper/Encryptable.o' 'dist/build/git-annex/git-annex-tmp/Types/Crypto.o' 'dist/build/git-annex/git-annex-tmp/Utility/Gpg.o' 'dist/build/git-annex/git-annex-tmp/Utility/PartialPrelude.o' 'dist/build/git-annex/git-annex-tmp/Utility/Directory.o' 'dist/build/git-annex/git-annex-tmp/Utility/Monad.o' 'dist/build/git-annex/git-annex-tmp/Utility/Data.o' 'dist/build/git-annex/git-annex-tmp/Utility/Applicative.o' 'dist/build/git-annex/git-annex-tmp/Utility/FileSystemEncoding.o' 'dist/build/git-annex/git-annex-tmp/Utility/PosixFiles.o' 'dist/build/git-annex/git-annex-tmp/Utility/Tmp.o' 'dist/build/git-annex/git-annex-tmp/Utility/UserInfo.o' 'dist/build/git-annex/git-annex-tmp/Common/Annex.o' 'dist/build/git-annex/git-annex-tmp/Types/Remote.o' 'dist/build/git-annex/git-annex-tmp/Utility/Base64.o' 'dist/build/git-annex/git-annex-tmp/Utility/Metered.o' 'dist/build/git-annex/git-annex-tmp/Git/Config.o' 'dist/build/git-annex/git-annex-tmp/Annex/Direct.o' 'dist/build/git-annex/git-annex-tmp/Annex/Direct/Fixup.o' 'dist/build/git-annex/git-annex-tmp/Git/CatFile.o' 'dist/build/git-annex/git-annex-tmp/Git/CheckAttr.o' 'dist/build/git-annex/git-annex-tmp/Git/CheckIgnore.o' 'dist/build/git-annex/git-annex-tmp/Git/SharedRepository.o' 'dist/build/git-annex/git-annex-tmp/Git/Queue.o'
Bug#628515: recommending verbose build logs
Bill Allombert wrote: The issue is that it is dangerous to upload packages built with a different DEB_BUILD_OPTIONS than the one on the buildd. Much less dangerous than it is to upload packages built with a different dpkg-buildpackage -j -- see shy jo signature.asc Description: Digital signature
Bug#720507: .dsc field for dgit [and 1 more messages]
Charles Plessy wrote: Le Sat, Aug 31, 2013 at 06:17:29PM +0900, Charles Plessy a écrit : In any case, we need one more Developer to support this patch before applying to the Policy. Once we have this extra assessment for consensus, I will apply it unless there are clear objections. Ping ? I support this proposal and this particular implementation of it. -- see shy jo signature.asc Description: Digital signature
Bug#720507: .dsc field for dgit
Charles Plessy wrote: About the specification of the commit hash: why is it not needed for a package uploaded to a given suite, that the commit is reachable in refs/dgit/suite ? AIUI this is because packages move between suites in the archive without that move necessarily being immediately reflected in a git repository. Also because dgit doesn't need that invariant to work properly. Also, what kind of commits in dgit repository are not reachable in refs/dgit/* ? Ones in refs/heads/master or refs/tags/ for example. Lastly, in case of the dgit repositories would move from the Alioth project 'dgit-repos' to somewhere else, could you propose a wording that is more generic, and that is more explicit on what a 'dgit-repos' is ? It may be too early to put a MUST in policy that would be broken if dgit.debian.net went away tomorrow. But I think what Ian is trying to do here is avoid the archive and dgit.debian.net becoming inconsistent due to a botched upload, as long as dgit.debian.net continues to exist and continues to contain a repository for a given package. It's reasonable to consider such an inconsistency a bug in the package, unless it somehow turns out to be a bug in dgit.debian.net. Maybe this is a better way to do that: When a git repository exists in the well-known dgit-repos location for the package named in ttSource/tt (which is currently defined to be ttgit://dgit.debian.net/dgit-repos//ttvarpackage/vartt.git/tt), the commit must be reachable in that repository from at least one git ref whose name matches ttrefs/dgit/*/tt (but not necessarily the ref ttrefs/dgit//ttvarsuite/var for the suite in which the file.dsc/file is found). -- see shy jo signature.asc Description: Digital signature
Bug#190753: Proposing to appeal to the tech. comittee about language extensions in scripts.
Charles Plessy wrote: As proposed in 2010 (http://bugs.debian.org/190753#98), I would like to ask the Technical Comittee to reconsider our Policy, and restrict it to cases where the name of a program is an interface (http://bugs.debian.org/190753#128). Actually, my message http://bugs.debian.org/190753#128 proposed exactly the opposite of what you say. Specifically, if the name of the program, including the extension, is an interface, then retain it. Note that interface is fairly broad and could include being used in lots of documentation, I suppose. I also suggested shipping a symlink for the benefit of users who don't want to remember implementation details. -- see shy jo, who originally wrote dh_* in shell script, just saying signature.asc Description: Digital signature
Bug#190753: programming languages suffixes
I'd suggest that, in cases where the name of a program is an interface[1], and includes the implementation language, it would be reasonable, and in the spirit of my original policy proposal, to ship a symlink that does not include the implementation language in its name, and retain the interface as necessary for compatability. It's reasonable to say a package doing that still has a minor bug, but at least it's a minor bug that does not inconvenience the user with suffixes. If there are multiple programs in different languages, with the same basename, then a symlink won't work; alternatives might, or not. But surely such a confusing situation is itself a (non-minor) bug, and very rare. Indeed, I can find no such cases in the archive. More commonly, there is a program with a language extension that is a wrapper around a binary without one (or in some cases, confusingly unrelated to the binary without the extension). I count 20 such in the archive. FWIW, I count[2] 158 programs in unstable with programming language extensions, and the same number in stable. Oldstable had 194. Not much progress but at least the number is not going up. If I could go back to 2003, I would have instead written a lintian check. [1] Let's be careful here; the name of a program is not in all cases an interface or API. If it were, any change to the name of a program would be a bug, and that's clearly not so. [2] zegrep '(^bin/|^sbin/|usr/bin/|usr/sbin/|usr/games/)' Contents-i386.gz|egrep -i '\.(php|py|pl|rb|hs|el|sh|tcl)' -- see shy jo signature.asc Description: Digital signature
Re: Bug#562874: Going back to lynx?
David Prévot wrote: Since there seems to have issues with html2txt, and the policy advises the use of lynx [0] No, policy gives an *example*, which happens to use lynx. what about reverting your almost ten years old change (#93747) and get back to depend on lynx ? If anything, I would be inclined to make it use w3m, which is now priority standard. But, consider: html changelogs are vanishingly rare (ie, 0.3% of the packages I have installed have one). html changelogs tend to have broken links (in 50% of the ones I surveyed). This is because /usr/share/doc/foo/changelog.html.gz tends to be copied to that policy-mandated location, while the files it links to are in /usr/share/doc/foo/html or /usr/share/doc/foo-doc/. As a corralary of the above, policy's handling of html changelogs basically requires that the changelog information be duplicated three times! Once uncompressed next to the other files that link to it; once as compressed html, which actually wastes space since it can't just symlink to the other location, and once as badly formatted plain text. My feeling is that the mention of html changelogs in policy is ill-advised, over-specifying what should be done in a minor edge case in a way that tends to result in bad solutions. IIRC, it seemed to make sense at the time that increasingly many packages would use html for their changelogs, but that does not seem to have happened. It would probably be better if policy just advised putting a pointer to the real upstream changelog in changelog.gz, and suggested that if the real upstream changelog were easily convertable to text, changelog.gz be built from it. -- see shy jo signature.asc Description: Digital signature
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
FWIW, the installation-locale udeb provides a C.UTF-8 locale, which d-i runs under. Takes about 168k. -- see shy jo signature.asc Description: Digital signature
Bug#492624: debian-policy: Allow internal debconf questions
Julian Andres Klode wrote: Quoting 3.9.1: Packages which use the Debian Configuration management specification must allow for trans- lation of their messages by using a gettext-based system such as the one provided by the po-debconf package. But internal debconf questions should not be translated, as they are not displayed to the user. Internal debconf questions are not communicated and thus are not messages. -- see shy jo signature.asc Description: Digital signature
Re: gnome, kde, xfce use non-policy main menu
Josselin Mouette wrote: Therefore, I still feel that, despite it being a big mess, the current situation is the best: * the default menu contains only what is needed, and we are still hunting down entries that are useless to make them not show up by default; * users wanting the Debian menu and its gazillions of entries including window managers, terminal emulators and shell interpreters can enable it easily in the menu editor; * those really wanting only the Debian menu can replace gnome-applications.menu by debian-menu.menu. If you want this to change, you need to seriously think about evolutions to both XDG and Debian menu systems, to convince fd.o and the Debian menu maintainer to implement them Actually, no, if you want this to change, you have only to do nothing. People (many of them MOTUs from Ubuntu in my experience) are filing lots of requestes for random packages to have .desktop files added to them, so they appear in the gnome menu. The criteria seems to be a program that $RANDOM_USER would like to have on the menu and files a bug about || that $RANDOM_UPSTREAM ships a desktop file for, for whatever reason. So, after sufficient time, the gnome menu will contain a random assortment of the menu items that also appear in the debian menu. Not a well-chosen and consistent assortment, but the kind of random assortment that you get when you ignore policy and go off on your own way. -- see shy jo signature.asc Description: Digital signature
Re: gnome, kde, xfce use non-policy main menu
Mikhail Gusarov wrote: fd.o menus are designed to allow distro-specific policy. It's the matter of Debian KDE/Gnome packaging/menu policy to get the proper subset of the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE menu and Qt/KDE - in Gnome one). That might work for gnome and kde, which are both fairly well defined, to ignore menu items belonging to each other, but won't it be a game of whack-a-mole for the rest of the things with menu entries? (Just for example, I recently orphaned xgalaga, so its new maintainers decided to do something about #432398, which I had been sitting on for some time as this issue was not resolved. Now I check my gnome machine and it has two galaga menu items in amoungst the standard gnome games.) -- see shy jo signature.asc Description: Digital signature
Bug#484511: Urgencies should all be lower case
Joerg Jaspert wrote: The code in dak, in the current form, is there since 2002-02-13, when jennifer (today process_unchecked) got added to the repository. Most probably something similar existed in the code before this. Its also nearly unchanged since then, with changes being cosmetical. Nice theory, but I have made many uploads with urgency=HIGH between 2001 and 2005 and did not receive any mails about an unknown urgency for those, but only for my last upload recently. -- see shy jo signature.asc Description: Digital signature
Bug#475101: obsolete linuxthreads requirement
Package: debian-policy Version: 3.7.3.0 Severity: normal You must specify the gcc option `-D_REENTRANT' when building a library (either static or shared) to make the library compatible with LinuxThreads. AFAIK we don't use linuxthreads anymore, and I checked a few libraries and failed to find them using such a flag. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- no debconf information -- see shy jo signature.asc Description: Digital signature
Re: Breaks in lenny
Russ Allbery wrote: I understand that you and a few other DDs feel that way, but you appear to be outnumbered at the moment. By whom? IIRC I've heard both release team and security team members state they prefer dealing with packages that don't use those things, and a majority of packages don't use them. (1698 packages build-depend on dpatch, 905 on quilt, 2767 on dbs, and 10793 don't.) Personally, I much prefer to work on packages where I'm not the maintainer if they use quilt and/or dpatch; it makes me far more comfortable than dealing with the giant wad of patch approach. Personally, when I was doing security work, if the package used those systems it either wasted my time and didn't get a security fix as quickly as possible, or got a non-ideal NMU that ignored it. Ditto for release work, RC bug squashing, and other frequent NMU work. Best practice is to use a proper revision control system (one which can do patch stack management if that's desired) and generate a consolidated .dsc/.diff.gz for people who don't want to get to grips with it. It may be that this will be what finally gets us away from using such tools, but I'm not sure how long it will take. 3714 source packages have Vcs-* fields, that's more already than those build-depending on quilt and dbs combined. (Ignoring the small number of cases that use both version control and quilt.) I'm happy to support going in that direction, but I think we'll need to be realistic about how long it will take to move the whole project. quilt and dpatch have been building momentum for quite a while now, taking over from the wad-of-patch approach, and any replacement will take at least as long (and probably longer if its not VCS-agnostic). My guess is packages with Vcs- fields will surpass packages using all 3 patch systems in the next 3 to 4 months. dpkg has only supported these fields since September. Many larger projects like pkg-perl and d-i have added the field to hundreds of their packages in version control and just haven't gotten around to uploading all of those packages yet. -- see shy jo signature.asc Description: Digital signature
Re: Breaks in lenny
Joey Hess wrote: 3714 source packages have Vcs-* fields, that's more already than those 2133 Bad grep that double counted packages with Vcs-Browser. I think the 4 month end of my estimate still stands. -- see shy jo signature.asc Description: Digital signature
Re: Breaks in lenny
Russ Allbery wrote: Bernd Zeimetz [EMAIL PROTECTED] writes: Which will only give useful results if we have a central repository for all packages. If $RANDOM maintainer uses his own machine to host a repository and goes MIA, you'll be left with one large and messy patch as you don't have access to the maintainer's repository. While using a RCS is not a bad idea, maintainers would need to be forced to use alioth - that's nothing you can force people to easily. A proper collection of patches - including descriptions - is the best way at the moment. The long-term possibility, which I think Ian may be alluding to without saying directly, is that some people are working on being able to ship the repository with the source package. If you're using something like bzr or git, you can then immediately start using regular VCS tools on the source package and the right thing will happen. I hope he was, and I hope this happens. (And my dpkg branch implementing it for git is still out there...) However, out of all the packages with Vcs-* fields, only about 400 (20%) don't use alioth. If maintainers going MIA and taking their version control repos with them becomes a problem, we could proactively mirror those onto alioth. A mirror that only ran when a new version of a package was uploaded shouldn't generate too bad load, especially for the ones already using distributed systems. -- see shy jo signature.asc Description: Digital signature
Re: Breaks in lenny
Russ Allbery wrote: Well, basically every discussion about this that I've seen on -devel, discussions on -mentors, the teams that I'm familiar with (pkg-perl is standardizing on quilt I'm a member of pkg-perl, and 52 packages out of ~500 use quilt. We also have 20 packages using dpatch, and 45 using dbs. One or two pkg-perl members like quilt, others, such as myself, find it of dubious benefit on top of a proper version control system (though certianly better than dbs!). -- see shy jo signature.asc Description: Digital signature
Re: Breaks in lenny
Russ Allbery wrote: Having the repository on alioth doesn't necessarily help if you're talking about something like Subversion (and particularly CVS) depending on the use case. I don't think we really get back the functionality of quilt until we're shipping the repository with the source package. Having access to a read-only Subversion repository doesn't really help with merging local patches into new upstream releases, for example Having a svn repo makes it fairly easy to update to a new upstream version. See svn-upgrade(1). (At least I assume svn-upgrade works about as well as my own svn-uupdate script that I've used for a thousand or so such updates, and which works about equally well as git-import-orig based on the 10 or so times I've used that so far.) -- see shy jo signature.asc Description: Digital signature
Re: RFC: cups as default printing system for lenny?
lpr's standard priority nonwithstanding, CUPS has been the default print system in Debian -- if you select the desktop or print server tasks -- for at least the last two releases. This is why popcon shows 5000 lpr installations to 45000 cupsys installations. Yes, it would make more sense for samba to default to CUPS, if there's some reason it can't probe/support both, and if it can't use the generic lpr interface also provided by cupsys. Yes, there's no reason to have any printing system at standard priority. A full CUPS install with all the PPDs and such would bloat standard enormously. Just making cupsys standard would perhaps allow spooling to remote printers from the command line, but not much else. d-i makes it easy enough to get CUPS installed. -- see shy jo signature.asc Description: Digital signature
Re: Mandatory support for -nocheck in DEB_BUILD_OPTIONS
Kurt Roeckx wrote: Atleast some packages now don't run the testsuite when DEB_BUILD_GNU_TYPE != DEB_HOST_GNU_TYPE. Are there any other reasons why testsuites shouldn't be run? Speed, and wanting to build a package even if its test suite is broken, I guess. Neil Williams wrote: There needs to be some agreement on what nocheck or notest means and which one to use. For Emdebian needs, whichever name is used, the imperative is that setting that DEB_BUILD_OPTION *must* completely prevent the execution of any compiled program within any test suite provided by upstream. Disabling such test suites in a cross compilation environment, as Kurt suggests, seems to me to make more sense that making notest really mean notest-involving-compiled-binaries. The only checks or tests that can be implemented outside nocheck|notest must only use system binaries from coreutils, binutils-multiarch or one of the gcc binaries. Is there some reason they can't use other system binaries, such as perl? (I'm thinking of the hundreds of perl packages that have test suites.) -- see shy jo signature.asc Description: Digital signature
Re: Mandatory -dbg packages for libraries?
Manoj Srivastava wrote: On Sun, 22 Apr 2007 19:29:55 -0400, Joey Hess [EMAIL PROTECTED] said: So while I'd love to have a way to have -dbg packages available for every binary, I actually am happy with this proposal to do it for only every library (plus whatever other binaries really need it). And it's a direction we're already moving in, with, as I mentioned, 227 lib*-dbg packages already in the archive. That's more than 10% of all our libraries already done[3]. So, making it a should would make 90% of our library packages insta-buggy. So I suggest that we take this as an existing practice, document it as a should in policy for now, document *how* to do separated debugging symbols in the developers reference (which does not currently seem to mention it at all), and go add -dbg versions of our library packages. I would rather add it as a recommended practice in policy, with a note that it will become a should/must as we get better coverage, and _also_ provide examples of what maintainers need to do to create separate debugging symbol packages in an informative footnote. Well, we've made more than ~300 packages insta-buggy with policy changes before. It's not insta-rc-buggy. OTOH, I don't really care; 300 bug reports could be mass-filed w/o it being a should in policy. Note that I've already written some documentation for developers-reference in #420540. The policy-relevant bits are that we use /usr/lib/debug/path-to-object, that the files should not be executable (possibly a common mistake since objcopy preserves executable bits IIRC), and that the package names end in -dbg and the debug packages depend on an equal version of the package they provide debugging symbols for. -- see shy jo signature.asc Description: Digital signature
Re: First draft of review of policy must usage
Otavio Salvador wrote: When I deal with my packages I put that kinda of bug in 'grave'. Doesn't mind to me if the affected group is 1 or 1k people. I'm talking about /bin/sh but it's far from that simple problem. That's the way people are handling bugs. In my POV the text that define the 'grave' severity doesn't say that you should ponder on how many people will be affected by the bug and then that shouldn't be used as a messure. The definition of grave is makes the package in question unusable or mostly so. If many people are successfully using the package, then it's not unusable, even if a few people cannot use it. Consider the Debian installer: It's usable by many users to install Debian on a wide array of hardware, but there are some sets of users who cannot use it -- for some people, it's still too hard to use; some hardware (in the past most SATA hardware) won't work; and some setups (like network installs over ppp) are not supported. None of these lacks mean that the Debian installer has a grave bug that should prevent it from being released. A grave bug in the installer is instead one that, for example, makes debootstrap fail halfway through. The number of people affected by a bug does affect its severity -- for sarge, it was reasonable to not consider lack of support for SATA hardware as RC, because the kernel support just wasn't there and clearly wouldn't be for a while, and because the majority of drives were not SATA. For etch, it makes sense to consider SATA issues as RC, because a lot more users will be affected by them. The or mostly so in the definition of grave severity is a hint that this severity is not a boolean, but a semi-arbitrary point along a scale. This is why there will from time to time be arguements about whether bugs are grave. -- see shy jo signature.asc Description: Digital signature
Re: Policy 3.7.0 - /usr/lib/cgi-{bin|lib}
sean finney wrote: this is a surprising change. guess that's what i get for not being subscribed to -policy :) Not really, it was last discussed on -policy in 2003, so being subscribed wouldn't have helped, I'm as suprised as you are. but i'm still grappling to understand the rationale behind why this is a desirable thing. if the desire is to provide a way for the local admin and packages to be able to share a script aliased directory, i would argue this is entirely the wrong way about it. i'd be happy to elaborate further. The rationalle is explained in #32263, though the logs are long. Here's the essence of it: On Thu, Nov 02, 2000 at 09:16:02AM -0500, Brian White wrote: - Most people setting up a web site expect /cgi-bin/ to be available for scripts on their site. Unfortunately, Debian uses this for those scripts packages that get installed. These two need to be independant. As such, Debian's system needs to be altered a bit. I recommend using instead the name /cgi-lib/ for scripts under /usr/lib/cgi-bin/. This will keep both features independant and not affect the general use of the system. Why this change was accepted into policy in 2006 when the last message about it was back in 2003, I have no clue. All that seems to have changed in between is the slight support for it that existed in 2003 bitrotting away. Despite the policy documents existing practice mantra, and despite indications in the bug log that bugs were being filed and web servers being updated in 2003 to support the cgi-lib scriptalias, as of now I can't find any web servers that actually support it or packages that use it: - apache2, the most used web server in Debian, doesn't support cgi-lib. Of course, apache2 was not in as wide use in 2003. - apache contains no references to cgi-lib and seems to not support it either. - boa, despite having a changelog entry about supporting cgi-lib in the default config, and despite including the empty directory in the deb, doesn't actually support it by default. - I can't find a single file shipped in /usr/lib/cgi-lib in all of Debian. - Some bugs that mention the directory, possibly not complete, but probably most of them: #167509 (cern-httpd; bug was closed when it was removed from debian) #167510 (aolserver; bug was fixed, but package is no longer in etch) #167511 (boa; badly fixed as mentioned above) #167512 (roxen; bug was fixed, although possibly not in the way policy intended, based on changelog, but package no longer in debian) #167513 (apache; tagged wontfix since 2003) To all indications, shipping any cgis in cgi-lib is premature and so was the acceptance of this policy amendment. i would argue that /usr/lib/cgi-foo is an outdated approach anyway, and that most applications ought to be scriptaliasing /package/cgi-bin or /cgi-bin/package to somewhere under /usr/lib/package (this would in fact be another use for the non-existant libexec dir...). but that's just my $0.02. Debian still has web servers other than apache2 in it, so that seems difficult to do. -- see shy jo signature.asc Description: Digital signature
Re: Policy 3.7.0 - /usr/lib/cgi-{bin|lib}
sean finney wrote: - that cgi-bin is defined to be a location outside of debian packages' reach entirely (/srv/www/cgi-bin or /var/www/cgi-bin, or whatever). - httpds which support scriptaliasing ship this as the default location - httpds which can not scriptalias it somewhere else (those that hard-code it at compile time, i'm guessing 0 may do this) use that as the location. - applications which wish to provide cgi-bin based scripts are allowed to use the scriptalias function of applicable httpds to claim subdirectories of cgi-bin. - under no circumstances are packages to place files in the default cgi-bin location. - it is the admin's privilege/responsibility/authority to modify the contents of the default cgi-bin location. AFAIK apache2 is the only web server package that allows scriptaliases to be added to it in a policy conformant way (by dropping config file snippets into /etc/apache2/conf.d/. Other web servers that support scriptalias, like boa, centralise it all in a single conffile, which other packages are not allowed to edit. That's why I said that there being more web servers than apache2 in Debian is a problem. with this approach, the admin is free to do whatever he/she wishes with the cgi-bin directory (place files, symlink to directories provided by debian packages, etc), without interference from debian packages. there is also a clear distinction of domain between the local admin and the debian package management system, which is generally a good thing and something we seem to like doing in debian. Of course using /cgi-lib/ for debian's cgis and /cgi-bin/ for the admin also draws a similarly clear distinction, although the naming of /cgi-lib/ could be clearer (as was mentioned in the policy proposal). -- see shy jo signature.asc Description: Digital signature
Bug#362247: no longer current regarding X font paths
Package: debian-policy Version: 3.6.2.2 Severity: normal Section 11.8.5. is no longer current regarding the font paths used by the new modular version of X. Packages providing fonts need to drop them into /usr/share/fonts/X11/ now, I guess. It would probably help if the X maintainers sent in a patch for this.. -- see shy jo
Bug#361137: [PROPOSAL] Make use of invoke-rc.d, if available, mandatory
Seconded once more. -- see shy jo signature.asc Description: Digital signature
Re: Make use of invoke-rc.d, if available, mandatory?
Lars Wirzenius wrote: Current policy states in section 9.3.3.2 (Running initscripts) the following: The use of invoke-rc.d to invoke the /etc/init.d/* initscripts is strongly recommended[51], instead of calling them directly. Footnote 51 further says: In the future, the use of invoke-rc.d to invoke initscripts shall be made mandatory. Maintainers are advised to switch to invoke-rc.d as soon as possible. I propose that the future has arrived. Seconded. (BTW, debootstrap should get changed sometime to use an invoke-rc.d policy instead of its current hack of replacing start-stop-daemon with a wrapper. d-i also diverts dtart-stop-daemon during the install, but only as a fallback in case a package not supporting invoke-rc.d is installed.) Here's the packages by maintainer BTW: Stefan Hornburg (Racke) [EMAIL PROTECTED] interchange Ben Armstrong [EMAIL PROTECTED] xpilot-ng Alan Bain [EMAIL PROTECTED] rbootd Mark Baker [EMAIL PROTECTED] exim-html exim-texinfo Mark Baker [EMAIL PROTECTED] exim Daniel Baumann [EMAIL PROTECTED] bricolage thttpd Kęstutis Biliūnas [EMAIL PROTECTED] freedict Ross Burton [EMAIL PROTECTED] avahi Scott M. Dier [EMAIL PROTECTED] bwbar Ludovic Drolez [EMAIL PROTECTED] adzapper Bernd Eckenfels [EMAIL PROTECTED] net-acct Khalid El Fathi [EMAIL PROTECTED] linuxlogo Turbo Fredriksson [EMAIL PROTECTED] libroxen-imho roxen4 tcpquota Stephen Frost [EMAIL PROTECTED] libnss-ldap Peter S Galbraith [EMAIL PROTECTED] xtide-data Bdale Garbee [EMAIL PROTECTED] gcpegg John Goerzen [EMAIL PROTECTED] dict-bouvier dict-gazetteer2k dict-moby-thesaurus Debian Firebird Group [EMAIL PROTECTED] firebird2 Debian Mono Group [EMAIL PROTECTED] xsp Debian QA Group [EMAIL PROTECTED] eco5000 slbreflex Steinar H. Gunderson [EMAIL PROTECTED] autofs Marc Haber [EMAIL PROTECTED] clamav-data Chris Hanson [EMAIL PROTECTED] oss-preserve Dan Helfman [EMAIL PROTECTED] php4-tclink Bob Hilliard [EMAIL PROTECTED] dict-devil dict-elements dict-gcide dict-misc Robert D. Hilliard [EMAIL PROTECTED] dict-jargon Simon Horman [EMAIL PROTECTED] heartbeat heartbeat-2 Ian Jackson [EMAIL PROTECTED] sauce Sam Johnston [EMAIL PROTECTED] reseed LaMont Jones [EMAIL PROTECTED] bind Karl E. Jorgensen [EMAIL PROTECTED] battery-stats Tibor Koleszar [EMAIL PROTECTED] apcd Yoshito Komatsu [EMAIL PROTECTED] canna-shion Jeff Licquia [EMAIL PROTECTED] diald Ola Lundqvist [EMAIL PROTECTED] ntop Cyril Martin [EMAIL PROTECTED] eagle-usb Jonathan McDowell [EMAIL PROTECTED] fidogate Steve McIntyre [EMAIL PROTECTED] nas Ricardo Javier Cardenes Medina [EMAIL PROTECTED] pipsecd Abraham vd Merwe [EMAIL PROTECTED] orca Michael Meskes [EMAIL PROTECTED] quota watchdog Millis Miller [EMAIL PROTECTED] iptotal Gergely Nagy [EMAIL PROTECTED] tama Jaakko Niemi [EMAIL PROTECTED] sfs Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] nessus-core Cajus Pollmeier [EMAIL PROTECTED] uif Simon Richter [EMAIL PROTECTED] towitoko Piotr Roszatycki [EMAIL PROTECTED] fonty Vladimir Shakhov [EMAIL PROTECTED] wdm Preston Smith [EMAIL PROTECTED] sendpage Teófilo Ruiz Suárez [EMAIL PROTECTED] boa Debian OpenSSL Team [EMAIL PROTECTED] openssl openssl097 Norbert Tretkowski [EMAIL PROTECTED] mailgraph Fumitoshi UKAI [EMAIL PROTECTED] fml Wouter Verhelst [EMAIL PROTECTED] nbd Michael Vogt [EMAIL PROTECTED] scanlogd Brian White [EMAIL PROTECTED] genpower jukebox-mercury squid-prefetch Discover Workers [EMAIL PROTECTED] discover James R. Van Zandt [EMAIL PROTECTED] adjtimex tony mancill [EMAIL PROTECTED] netsaint-statd Sam Hocevar (Debian packages) [EMAIL PROTECTED] gnudip -- see shy jo signature.asc Description: Digital signature
Bug#344310: policy is out of date re tasks and tasksel
Package: debian-policy Version: 3.6.2.1 Severity: normal 3.9 does not describe the current tasksel/tasks situation very well. You should not tag any packages as belonging to a task before this has been discussed on the _debian-devel_ mailing list and a consensus about doing that has been reached. Actually developers should never add Task fields; they are added via overrivdes that are taken from tasksel's lists of tasks. The contents of tasksel's tasks are determined by the various maintainers of those tasks. For third parties (and historical reasons), tasksel also supports constructing tasks based on _task packages_. These are packages whose names begin with _task-_. Task packages should not be included in the Debian archive. Tasksel has not supported task packages since sarge's release, although it does provide other useful ways for third parties to define tasks without using the Task fields. -- see shy jo signature.asc Description: Digital signature
Re: GNUstep and FHS
Ola Lundqvist wrote: Hello On Sat, Jul 30, 2005 at 12:00:32PM +0200, Marc 'HE' Brockschmidt wrote: Ola Lundqvist [EMAIL PROTECTED] writes: I do not really see a problem here. All gnustep packages store files in a (at least sort of) FHS compliant directory: /usr/lib/GNUstep Are the files stored there only object files, libraries and internal binaries not intended to be executed directly by users? [This is quoted From the FHS] FWIW, Marc's quote is not accurate, the exact text is: /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. Arguably the includes leaves open the possibility of other files being in /usr/lib. Architecture specific game levels and other similar data files might be one example. If that is what we want to enforce we have to remove/fix a LOT of packages. Here is just a few that break that: * dpkg dpkg mostly breaks the FHS by placing large quantities of static files in /var/lib/dpkg. :-P * subversion subversion's hook scripts can be binaries as well as scripts. There's a README which it would be pretty silly to move to /usr/share when some of the the hooks it documents are in /usr/lib. Splitting the hooks and README up for scripts/binaries would make it harder to find useful hooks. * lilo * sawfish * python (all python packages) * openoffice * gnumeric * perl (dpkg -L perl | grep /usr/lib | grep pm$) The reason these files are in /usr/lib has been previously discussed, IIRC. * tasksel ... and probably many many more ... These was the ones that I found on a quick look on my own installation... To take the example I am most familiar with, tasksel uses /usr/lib/tasksel/tests/ to contain various executables, which can be added by third parties. Currently they are all architecture indep, but that could change. Making tasksel look in both /usr/share and /usr/lib for this is unnecessary complexity and bloat. Also, tasksel uses /usr/share/tasksel/ for a single specific purpose, and third party files can be placed there to modify its behavior, so moving anything into /usr/share/tasksel would break backwards compatability. So the 20k of arch indep data that tasksel currently puts in /usr/lib is just not worth the pain to remove it. We have to keep in mind the reason /usr/share was split out and not go overboard in splitting out architecture independent data when it doesn't really matter. And there are also some directories that are common between applications that break this (arch indep things in /usr/lib). * /usr/lib/menu (!) This is in the process of being moved to /usr/share. There's actually a very good parallel with tasksel here, the difference is mostly the size of the directory contents. * /usr/lib/mime Similar to /usr/lib/menu actually. * /usr/lib/emacsen-common 52k of data is probably not enough to worry about. -- see shy jo signature.asc Description: Digital signature
Bug#190753: Bug #190753 (frown on programs in PATH with language extentions)
Michael Shields wrote: What ever happened with this proposal you made in April 2003? Is it waiting on something? Good question. I don't know why this accepted policy amendment with no dissenters and three seconds hasn't been included in any of the three releases of the policy manual made since it became an amendment. I do know that I file bugs on any program I see being named with an extension of a programming language, and in the main they get fixed. -- see shy jo signature.asc Description: Digital signature
FHS version for etch
Debian policy is still stuck requiring FHS 2.1, although a copy of FHS 2.3 is included in the debian-policy package. As noted in bugs 212434 and 230217, the changes needed to upgrade to 2.3 are not too large, and consist of: 2.1 to 2.2: - new location for adjtime file (#156489) - #212434 and the FHS 2.2 announcement also mention a hwclock move to /usr/sbin, but I cannot find a mention of a location for hwclock in FHS 2.2 or 2.3. 2.2 to 2.3: - Addition of /media. Fully set up on new sarge installs, although an incomplete transition means we still have a /cdrom - /media/cdrom symlink. apt-cdrom will need some fixes before that link can be removed. Automatically transitioning a running system to /media is probably either impossible or a really bad idea. We will need to document it in the release notes as a transition admins may want to do, and will need to preserve backwards compatability for /floppy and /cdrom if they exist to avoid breaking running systems. - Addition of /srv. Directory exists, most things that could potentially use it do not yet by default do so. FHS does not specify that everything has to use it, so we already comply with the letter of the FHS. Policy should probably encourage servers to use this directory when appropriate, and we may want to adopt a policy for what kinds of subdirectories should be used in it by default. The FHS does not specify this, but gives the example of structuring it by protocol, which might be a good default for Debian. Note that the existance and use of /var/www has always been a FHS violation, which using /srv will finally let us correct. - Requires amd64 to use /lib64 for 64 bit binaries. I'm told this is not present in our amd64 architecture. I suspect this is overspecified in the FHS and policy should excempt ia64 from the requirement, although someone should make sure /lib64 works if a extra-Debian source puts a library there. - Requires a /usr/local/share/man be synonomous with /usr/local/man. We do not have a /usr/local/share/man, and will need to add such a symlink to comply. - Requires boot loader configs in /etc, but does allow them to just be symlinks to the real location (ie, /etc/grub/menu.lst - /boot/grub/menu.lst). We do not have such symlinks for at least grub, didn't check ia64, powerpc, sparc, and other arches that have bootloader config files. We will need to fix this. Seconds: 2.2: Martin Michlmayr Matthias Urlichs Scott James Remnant Branden Robinson 2.3: I second moving to 2.3. We've already made significant progress in that direction and the work remaining to be done seems easily accomplished in the etch timeframe. BTW, current LSB versions require these new versions of the FHS. -- see shy jo signature.asc Description: Digital signature
Re: FHS version for etch
Manoj Srivastava wrote: The reason this has not changed is because back in october, we had a large, unresolved discussion both on the policy and the devel mailing lists that went over the changes, point by point, and people pointed out that there were obstacles to just recommending the move to 2.3 Not really that long a thread. Anyway the only points brought out in that thread that I missed in my summary are: - Mentions XF86Config config file by name. But calls it optional and notes it's for version 4 of XFree86, and also mentions the old Xconfig file, so it seems x.org can slip in without problem although the current XF86Config-4 violates the FHS. - Over-specific new requirements for dotfiles. Could be weakened in debian policy to a recommendation (or requirement; makes Gnustep buggy) that config files in $HOME begin with a dot, and that throws out the other requirements. -- see shy jo signature.asc Description: Digital signature
Bug#225465: Suggested course of action to close this bug
Mark Brown wrote: On Tue, Dec 30, 2003 at 10:18:18AM -0200, Henrique de Moraes Holschuh wrote: On Tue, 30 Dec 2003, Dan Jacobson wrote: not restart the services on package upgrades. Broken ones still calling /etc/init.d/whatever directly will, but that's a bug: report it whenever you find one of these packages. Packages using debhelper appear to still use /etc/init.d directly. Not really: # Automatically added by dh_installinit if [ -x /etc/init.d/mooix ]; then update-rc.d mooix defaults /dev/null if [ -x /usr/sbin/invoke-rc.d ]; then invoke-rc.d mooix start else /etc/init.d/mooix start fi fi # End automatically added section -- see shy jo signature.asc Description: Digital signature
Re: draft proposal for a new web server policy
Fabio Massimo Di Nitto wrote: I am cross posting this answer but I think we should keep the discussion on one mailinglist only. I leave up to you which one you think is more appropriate. I'd prefer debian-policy. - Some web servers (eg apache2) can cooexist with other web servers installed concurrently. But historically we've had the debian web server install a default /var/www/index.html particular to that server, and only one web server can do that at a time. So apache2 currently violates debian policy by using a different directory as its web server root. Which leads to many other administration problems, such as anything dropped in /var/www not being available under apache2. We should consider 2 options to address this problem: 1) provide a single default DocumentRoot for all webservers with a common Debian entry page (as suggested by aj and DanielS on irc) and a possible /serverinfo/ to let the user verify immediatly which server is accessing (in case of multiple web servers running at the same time as suggested by DanielS) I would be ok with this, except I think that it should be /debian-www/serverinfo to avoid eating more namespace. It would however, be a bit harder to transition to doing this. 2) provide a default DocumentRoot for each webserver where we can store the default pages we are actually shipping. Personally i prefer 2 but of course i will let users decide what they prefer. So the idea of the proposal is that a web server, after choosing the directory to use as the document root (possibly prompting the user), would set it up with its index.html and a link to debian-www. Presumably index.html is copyied in from somewhere, but the proposal also leaves it open to be created from a postinst, or not included at all. I'm not sure if there is any benefit to something standard like /usr/share/httpd/defaultdocumentroot. Maybe there is, if some program external to the web server wants to set up a later vhost for that web server. In any case, it would not be a formal DocumentRoot, but would instead be more of a document skeleton directory that is copied or linked into place. - If you use vhosts, you can only have one pointing to /var/www, so only one will get the debian content provided there. To add it to the others, you have to maintain lots of symlinks. Even if it is not our task I would like to at least suggest users a common schema on where to store vhosts and possibly in a future having a small tool to handle them. It would make life easier for users approching the first time httpd. I'm sure personally that this will be /srv in the future (but time will tell). Wouldn't a tool to handle vhosts be fairly specific to the httpd? Under this proposal it could create the debian-www link, could copy in files from a /usr/share/httpd/defaultdocumentroot if we go that route, but would have to hook into something that knows about the web server to configure it. Anyhow, the details of that are, I hope, outside this proposal. 11.5.2. URLs for web-accessible content This section specifies the URLs that should be used to access web-accessible content provided by the Debian system. The Debian web content will be available at the URL http://site/debian-www/. This includes http://site/debian-www/cgi-bin for CGI programs, http://site/debian-www/doc for documentation, and http://site/debian-www/application for web application data. These URLs should also work for any virtual hosts on the Debian system, unless the administrator has chosen to not include the Debian content on a virtual host. I think this can be interpreted in 2 different ways but please correct me if i am wrong. What I read here is: - all the links/urls/references must be relative (so no encoding of site) or (and this probably apply to apache* only): - if debian-www is not found on the specific site try to access the default one (that it is possible when specifing aliases at global level other than per vhost base) I am farly sure you mean the first, don't you? I meant the first (the second would break at least vhost aware cgi scripts like mailman). However, I hadn't thought that relative urls would be a consequence of it; it's ok if mailmail encodes site in an url, as long as that url is generated on the fly for a given site. Certianly no urls encoding the site name in static content. If they include an index.html (or localised index.html.ll or similar files) there, they must take care to not overwrite files created by the administrator, or by other web servers, and removal of the web server should remove those files. I think the removal has to be done if we isolate these files where the user is not supposed to touch them. At this point in time where we use /var/www we do not touch them. (at least apache doesn't).
Re: draft proposal for a new web server policy
Daniel Stone wrote: I'm not sure I love the /debian-www/ bit; it's a bit aesthetically displeasing, but to each their own. Good idea otherwise, however. I agree, it is not the prettiest name. I considered just /debian/, but it seemed more likely that would conflict with something on someone's web server. Do note that there is nothing stopping an admin from linking /foo/ to /debian-www/. They'll have to keep /debian-www/ around because of links that will refer to it, but they can use whatever prettier url they can come up with. So it's not too bad. I suppose the other achoice is to put all Debian content in /debian-www/, and only have index.html redirecting to /debian-www/, so that way the user only has to overwrite a ~100-byte file. Or something. That's a pretty good idea, if it can be done without ugly timeouts in redirect and with localisation still working. -- see shy jo signature.asc Description: Digital signature
draft proposal for a new web server policy
Maybe it's time to think about amending section 11.5. of policy (Web servers and applications) to address some of the problems with it. Here are the problems I know of: - Some admins want to tightly control which cgi scripts are available, beyond merely picking packages to install. For example you might want to install analog without activating its cgi script. - Some admins may need to use http://host/cgi-bin/ for their own custom cgi scripts for historical or local policy reasons, but would also prefer to be able to use cgi scripts from debian packages, without tracking/linking them on a per-package basis. - Some might want http://host/doc to be their own content, and not the debian docs. I think the Debian web site is one example. - Some web servers (eg apache2) can cooexist with other web servers installed concurrently. But historically we've had the debian web server install a default /var/www/index.html particular to that server, and only one web server can do that at a time. So apache2 currently violates debian policy by using a different directory as its web server root. Which leads to many other administration problems, such as anything dropped in /var/www not being available under apache2. - If you use vhosts, you can only have one pointing to /var/www, so only one will get the debian content provided there. To add it to the others, you have to maintain lots of symlinks. - /var/www violates the FHS. Of course the FHS has not laid out a place for web stuff, though they might eventually with /srv. This proposal does not mandate /srv, but it does lay groundwork to make it ok for web servers to use /srv when it becomes part of the FHS, and to help make it easier to transition to it. - Any others? I notice that many of these come down to a namespace problem. We have appropriated the default top-level namespace of the web server for Debian-provided content, which doesn't give the admin enough control. If they take back control, for example by changing the web document root to /home/web or /srv/web, and creating their own cgi-bin directory, then they lose all the benefits of the Debian integration. Unfortunatly many hrefs are absolute, and so they break when you do things like this, so even making http://host/debian link to all the debian provided stuff is not feasable without a lot of work. This brings me to the policy proposal: -- 11.5. Web servers and applications 11.5.1. Filesystem locations for web-accessible content This section describes the filesystem locations that should be used for web-accessible content provided by the Debian system. CGI executable files are installed in /usr/lib/cgi-bin/cgi-name. HTML documents for a package are stored in /usr/share/doc/package. Web applications should store static web-accessible files (icons, non-documentation html pages, etc), under /usr/share/package and /usr/lib/package. Variable web-accessible files (such as mrtg graphs) may be stored under /var/lib/package. Web applications may also store web-accessible files in /var/www/, but use of this directory is deprecated and will become a bug in a future edition of Debian policy. All of the above content is gathered together in the directory /var/lib/debian-www/, which includes links to /usr/lib/cgi-bin/, and /usr/share/doc, and to which links can be added to content in /usr/share/package, /usr/lib/package, /var/lib/package, and /var/www (deprecated). Packages should only add symlinks, and possibly subdirectories to the /var/lib/debian-www/ directory, and not actual content. 11.5.2. URLs for web-accessible content This section specifies the URLs that should be used to access web-accessible content provided by the Debian system. The Debian web content will be available at the URL http://site/debian-www/. This includes http://site/debian-www/cgi-bin for CGI programs, http://site/debian-www/doc for documentation, and http://site/debian-www/application for web application data. These URLs should also work for any virtual hosts on the Debian system, unless the administrator has chosen to not include the Debian content on a virtual host. The following URLs may be used for Debian provided content, but are deprecated in favor of the new URLs listed above: http://host/cgi-bin/ for CGI programs. http://host/doc for documentation. 11.5.3. Web server configuration and virtual hosts Web servers should ship with a default configuration that may include a default front page, specfic to that web server, at http://site/, and must include http://site/debian-www/. The web server should restrict access to http://site/debian-www/doc so that only clients on the same host
Bug#222553: policy 11.5.3 refers to using the menu package to register docs
Package: debian-policy Version: 3.6.1.0 Severity: normal Section 3.6.1.0 of policy recommends registering HTML documents with the menu package. AFAIK this practice has been supersceded by doc-base. Although oddly, I see no mentions of doc-base in policy. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux dragon 2.4.22 #1 Sun Oct 12 15:11:10 EDT 2003 i686 Locale: LANG=en_US, LC_CTYPE=en_US -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Josip Rodin wrote: Well, regardless of whether we pick versions or listing available targets, why not do it with a new control file field in the source section? That seems logical, and avoids creating a new file. It's tangentially relevant that the .dsc and .changes files include a Format field that is a version number. Having a Rules-Format: 2 field in control seems okay to me. I agree that this would be the way to go (though I'm ambivilant about the proposal). -- see shy jo signature.asc Description: Digital signature
Re: Bug#209008: debian-policy: [PROPOSAL] common interface for parallel building in DEB_BUILD_OPTIONS
Colin Watson wrote: Using separate environment variable names would fix that problem, not that I particularly relish the idea of trying to get it changed everywhere. Me either. If we didn't want to change the existing flags, we could still reserve DEB_BUILD_OPTIONS_* for extensions. I'd like to do this, and see new stuff that comes into policy use the saner form. Especially if it's something like this proposed option, which has a nonboolean value. -- see shy jo pgpqC2bElouK6.pgp Description: PGP signature
Re: Bug#209008: debian-policy: [PROPOSAL] common interface for parallel building in DEB_BUILD_OPTIONS
Robert Jordens wrote: +ifneq (,$(findstring parallel,$(DEB_BUILD_OPTIONS))) +PARALLEL_JOBS := $(shell echo $(DEB_BUILD_OPTIONS) | \ +sed -e 's/.*parallel=\([0-9]\+\).*/\1/') +ifeq ($(DEB_BUILD_OPTIONS),$(PARALLEL_JOBS)) +PARALLEL_JOBS := $(shell if [ -f /proc/cpuinfo ]; \ +then echo `cat /proc/cpuinfo | grep 'processor' | wc -l`; \ +else echo 1; fi) +endif +endif +MAKEFLAGS += $(NJOBS) That's a lot of boilerplate, almost enough to call for a program to parse DEB_BUILD_OPTIONS. I don't understand why we have an environment variable with a complex set of values in the first place. Surely something lile DEB_BUILD_OPTIONS_PARALLELL=n, DEB_BUILD_OPTIONS_NOPT, and DEB_BUILD_OPTIONS_NOSTRIP would not run us out of environment space, and it's far easier to work with. BTW, the link you gave appears to be to a large thread that covers a lot of unrlated ground. I have not found any technical problems with MAKE=make -jn in it yet, but then I'm on dialup. -- see shy jo pgpq8FGVbUaRa.pgp Description: PGP signature
Re: build-depends-indep and arch: all source packages
Andrew Suffield wrote: Isn't useless makework for the maintainer the point of lintian/linda? :P :-) The value is rather limited though... two cases I can think of, are trying to build the arch-dep components (which should do nothing, successfully) and adding an arch-dep component to the package later. Building arch-dep would still work of course, it would just load a lot of unnecessary build deps and then do nothing, successfully. This is not a case I am very interested in optimizing, since there is a nice optimisation -- check debian/control for arch-dep components before building.. If the package gets an arch-dep component later, I will probably be in a better position than I am in now to figure out what should go in the build-depends and what could split out into build-depend-indep. Since it's also statisitcally unlikely, I'd worry about it when it happens. -- see shy jo pgpNvlzBPfuMZ.pgp Description: PGP signature
build-depends-indep and arch: all source packages
A strict reading of policy now indicates that Build-Depends-Indep need not ever be satisfied when the clean target is called. Apparently this change was made to document autobuilder behavior when building packages that mix arch all and arch any components, but as I read it, the effect is broader. If build-depends-indep need not be satified any time the clean target is run, then I can imagine that some tool might be written to rely on that, and only install the build-depends before building a package that is only arch: all. Therefore it seemed to me that I should change the dozen or so arch all pacages I maintain to put debhelper in the build-depends (and generally everything in the build-depends for most of them since the split is useless unless the package builds both arch all and any and has a properly structured debian/rules -- only one of my packages bothers with that). When I did, linda complained: W: liblingua-en-words2nums-perl; Package has Build-Depends, but builds no arch-dependant packages. Is linda behind the times, or am I trying to follow policy too closely? Is this build-depends-indep split really of any value, or is it just complicating our lives for no good reason? -- see shy jo pgpUvhPNxbKwg.pgp Description: PGP signature
Re: build-depends-indep and arch: all source packages
Joey Hess wrote: If build-depends-indep need not be satified any time the clean target is run, then I can imagine that some tool might be written to rely on that, and only install the build-depends before building a package that is only arch: all. Rather, that some tool remove the build-depends-indep before cleaning such a package, and then expect the clean target to still work. Therefore it seemed to me that I should change the dozen or so arch all pacages I maintain to put debhelper in the build-depends (and generally everything in the build-depends for most of them since the split is useless unless the package builds both arch all and any and has a properly structured debian/rules -- only one of my packages bothers with that). When I did, linda complained: W: liblingua-en-words2nums-perl; Package has Build-Depends, but builds no arch-dependant packages. Is linda behind the times, or am I trying to follow policy too closely? Is this build-depends-indep split really of any value, or is it just complicating our lives for no good reason? -- see shy jo pgp4NHsXho4Dc.pgp Description: PGP signature
Re: build-depends-indep and arch: all source packages
Wouter Verhelst wrote: This has led to the confusion that people thought build-depends were intended for arch-dependent packages *only*. That isn't true. Build-depends should contain build-dependencies that are common to arch-independent and arch-dependent packages, as well as build-dependencies that are needed for arch-dependent packages only. In the current implementation, build-depends should be thought of as the combination of Build-Depends and a hypothetical Build-Depends-Arch. In this case, since there is no 'clean-arch' or 'clean-indep' package, the clean target is common by definition, and thus any build-dependencies required for the clean target should be put in the build-depends field. Therefore, if linda suggests to put all build-dependencies of arch-indep only source packages into build-depends-indep, it is not just behind times; it is also suggesting something which is not following the spirit of what build-depends/build-depends-indep was created for; nor has it ever been -- although I must admit that my own arch-indep only package incorrectly puts everything in build-depends-indep, too. FWIW, here's linda's rationalle for its warning: W: apt-src; Package has Build-Depends, but builds no arch-dependant packages. Package being checked declares Build-Depends, but does not actually build any architecture-dependant packages. You should consider using Build-Depends-Indep. I suppose I'll just ignore this warning. It should probably be replaced with a new warning that checks to see if debhelper is in the Build-Depends-Indep and if so warns that it needs to be in Build-Depends for dh_clean to be guaranteed available to the clean target. -- see shy jo pgpiUVXwZlM5A.pgp Description: PGP signature
Re: build-depends-indep and arch: all source packages
Andrew Suffield wrote: Not quite; it should be modified to explicitly exclude debhelper. There are very few packages which are actually needed at clean time - the warning is correct for most things. That does not agree with what Wouter said. Wouter Verhelst wrote: When build-depends were first created, people started adding build-depends for arch-independent packages in multi-binary source packages, resulting in waste of resources by autobuilders installing packages they won't need to build the package. Build-depends should contain build-dependencies that are common to arch-independent and arch-dependent packages, as well as build-dependencies that are needed for arch-dependent packages only. If a package is strictly arch-indep, then nobody is likely to benefit from the build-depends being split into the pieces needed to run binary-indep, and the peices needed to run clean. It's just useless makework for the maintainer. -- see shy jo pgpsni9WRbeKa.pgp Description: PGP signature
Re: ADMINISTRIVIA: Comments on old bug reports
Manoj Srivastava wrote: * #172436: debian-policy: [PROPOSAL] web browser url viewing Package: debian-policy; Reported by: Joey Hess [EMAIL PROTECTED]; days old.236 This proposal was initially seconded, but then discussion turned up some problems, and a modified proposal was put forth. The last message in the BTS asked for a new set of seconds; if interest is shown in the new wording, this can be fast tracked into policy, since discussion has already happened. I am still seeking seconds for this proposal, since I feel it is important that policy document how url viewing is handled in debian, and that future browser using programs be packaged using the new methods rather than hardcoding calls to netscape. -- see shy jo pgpeQ3McS4jNP.pgp Description: PGP signature
Bug#203650: Poor recommendation in dpkg-statoverride section
Jakob Bohm wrote: Note that only a few packages will need these dependencies, unlike libc6. Specifically, these packages will be needed by a subset of the packages that currently Depends: adduser . You have to depend on adduser? Oops. Adjust your numers accordingly. :-) -- see shy jo pgpoFZkduq3j3.pgp Description: PGP signature
Bug#172436: Security concerns regarding browser proposal
Matt Zimmerman wrote: It might be a good idea to specify how quoting should be handled, both for shell metacharacters and format specifiers. Well, it's been discussed several times before, but what the hey, I guess I can discuss it one more time. My browser proposal assumes that sensible-browser and/or the actual browser itself not be called via system or other shell interfaces. With that caveat, they are secure from url attacks. From the existing text, it seems that command part means shell command part, and it is impossible to implement this securely without specifying a scheme for handling shell metacharacters. See, for example, the recent xpdf discussions, where the URL-handling command could be exploited by a URL containing metacharacters if it did not quote the argument. Even if the command includes quotes around a substitution variable such as %s, the caller MUST quote any quote characters in the URL itself in order to be secure. No, the caller MUST NOT pass urls through the shell in order to be secure. Quoting an earlier post of mine in response to Ian Jackson raising the same question, archived in this same bug report: The code in Debian already (see the sensible-browser program) does not let BROWSER touch a shell. If BROWSER contains a %s then the command is all parsed into words, substituted, and the browser execed. Just as Ian goes on to suggest we do, except we keep the %s available as the upstream BROWSER environment variable spec calls for, with no additional security issue. I think there was already a thread about this. The only possible security problem comes if some badly behaved program does this: system(sensible-browser 'url'); Such programs are broken, but it's breakage outside the scope of this proposal. I'd be happy to see someone make a proposal that programs not pass any kind of tainted data through the shell, ever, but someone else will need to work on that. :-) Every program I have converted to comply with the browser policy calls sensible-browser safely, using exec, or parses BROWSER on its own and runs the browser itself safely, using exec. The semantics for %s and %% so closely match printf that they beg to be implemented using printf itself. This means that % characters also present a security risk through well-known format string attacks. The %s thing can only be injected by a user modifying his own BROWSER variable. I think we can assume such a user already has shell access. If we were starting from scratch, it would be simpler to address these concerns, but since we are trying to follow esr's proposal, it seems more complicated. I consider the specification to be flawed if it does not address these security concerns. The example given in esr's document: BROWSER=netscape -raise -remote \openURL(%s,new-window)\:lynx is easily exploited by a URL such as: http://my.fun.site/;; echo Do bad things Except that in the current implementation in sensible-browser, the above attack does not work. (BROWSER is split into words, the %s is substituted, and the lot is passed to exec[1]) ESR clearly did not think much about security when designing the upstream proposal, but it is not impossible to implement it safely. Also, www.tuxedo.org/~esr/ is no more. A working URL is: http://catb.org/~esr/BROWSER/ Good catch, consider my proposal updated. -- see shy jo [1] My invocation of exec in sensible-browser may not be immediatly obvious, since it looks like system, but read the perl manual. Vive la obfuscation. pgpNrpeEqDPCa.pgp Description: PGP signature
Bug#172436: Security concerns regarding browser proposal
Colin Watson wrote:
On Sun, Aug 03, 2003 at 07:48:43PM -0400, Matt Zimmerman wrote:
It might be a good idea to specify how quoting should be handled, both for
shell metacharacters and format specifiers.
Odd, I thought I'd mentioned
http://www.dwheeler.com/browse/secure_browser.html in this bug, but
evidently not. man implements the Compatible Secure BROWSER Definition
from that page. It's about 50 lines of C, not counting an escape_shell()
utility function.
We could also go for the Alternative definition on the same page, which
acknowledges that you probably need a helper script anyway to do the
complicated Netscape/Mozilla stuff and ditches the % characters
entirely. I don't have any strong feelings about which to use.
That page was brought up in one of the thread leading to this bug
report. In my reply to you [EMAIL PROTECTED],
I said:
I assume you mean the compatible alternative and not the bare one
(though there's something to be said for the bare one; wrappers are not
hard to write).
First of all, it's possible to write a program that uses ESR's BROWSER
without passing the url through the shell. Here is a modification of my
sensible-browser program that does that:
--- sensible-browser~ 2002-11-19 12:20:14.0 -0500
+++ sensible-browser2002-11-19 12:20:31.0 -0500
@@ -11,7 +11,7 @@
else {
$_.=' '.$url;
}
- exec $_;
+ exec split ' ', $_;
# on failure, continue to next in list
}
Before:
[EMAIL PROTECTED]:~BROWSER='echo' ./sensible-browser 'http://;echo rm -rf /'
http://
rm -rf /
After:
[EMAIL PROTECTED]:~BROWSER='echo' ./sensible-browser 'http://;echo rm -rf /'
http://;echo rm -rf /
So is the increased complexity of making %s be converted to an escaped
absolute reference worth it? I note that the definition of escaped
absolute reference uses a hardcoded list of shell metacharacters to
escape. Such lists are often incomplete, I've seen exploits on bugtraq
of this kind of thing in the past. It seems easier to just program
defensively, not pull the shell into the picture, and not worry about
escaping.
The secure browser page does mention wanting to pass the BROWSER command
through the shell for backwards compatability (with what one wonders)
and to allow complicated shell expressions in BROWSER. I think that's a
bit of a non-starter; if you need something complicated you can
certianly write an external script. The complexity outweighs the gain.
How about we just add something like this to the proposal:
When implementing BROWSER in a program, be careful to not pass the URL
through the shell when running the browser commands, as the url might
contain shell metacharacters and there could be security problems. If
you must pass the URL through the shell, be careful to properly escape
it first.
Which, I think, ended that, although that paragraph was never added to the
proposal.
--
see shy jo, replaced with a mail archive grepper for this thread
pgpnHLCID9Gah.pgp
Description: PGP signature
Bug#203650: Poor recommendation in dpkg-statoverride section
Andrew Suffield wrote: Hold that thought. We hashed out a few ideas on IRC; more in a few days. Meanwhile, let's assume it will be solved... anything else? I missed that discussion, but the obvious approach in fakeroot is user autovivification (to bottow a term from perl) on chown. -- see shy jo pgpwkhfIYvLvs.pgp Description: PGP signature
Re: Deconf and shared questions
Manoj Srivastava wrote: How does one discover these templates then? Is this a hit-or-miss effort based on the packages I may have installed on my machine? Seems to me that makes it very likely that the user shall be bombarded with identical questions on install then; I think this would be quite irksome. namespace.txt in debconf-doc gives some general rules and documents a few of them. I will be glad to add more. Or this could be moved into a file included in policy and maintained that way. The shared/ toplevel heirarchy seems to be popular for this sort of thing, at any rate; even related packages seem likely to use this when the question doesn't clearly belong to just one of them. OK. How do I discover the templates in the shared hierarchy, then? As for owning the template: /all/ of the packages own the template (as shown by the Owners: field in /var/cache/debconf/config.dat), and must ship it; or there must be a common package that all others depend on which owns the question, if including it in multiple Assuming one knows which package this is. Also, do all these templates have to be identical? If not, which template determines the question that is asked? Shared templates should be identical and must be duplicated in all packages that use them. The most recent text debconf sees will be used. I am not sure where I stand on the tradeoff between multiple, redundant questions being asked in the preconfigure phase, or a single question being asked in the postinst (since subsequent postinsts would not ask the question since /etc/news/organization would exist). I tend to lean towards the single question. There is no need to ask questions in the postinst. It works like this: - preinst a asks shared/foo: unseen so displayed - preinst b asks shared/foo: seen, so question skipped ... - postinst a acts on shared/foo - postinst b acts on shared/foo ... -- see shy jo pgpE54wd9iDtF.pgp Description: PGP signature
Re: Bug#176506: Proposal seconded...though very late..:-)
Mark Baker wrote: I believe exim4 should be the default mailer by the time sarge is released, at least if its maintainers believe it is stable enough (I'm now using it myself on my server, and I believe that it is). Has there been any progress on getting exim4 into base yet? It's best to do these things earlier rather than later, bear in mind that I have to update base-config when that change is made, and get it all tested and so on. -- see shy jo pgpTWc4E9x9Lc.pgp Description: PGP signature
Re: Bug#176506: Proposal seconded...though very late..:-)
Josip Rodin wrote: On Sat, Jul 12, 2003 at 12:25:50AM -0400, Joey Hess wrote: I believe exim4 should be the default mailer by the time sarge is released, at least if its maintainers believe it is stable enough (I'm now using it myself on my server, and I believe that it is). Has there been any progress on getting exim4 into base yet? It's best to do these things earlier rather than later, bear in mind that I have to update base-config when that change is made, and get it all tested and so on. Do you mean that just for new installations or also for upgrades from exim 3? It would be nice and consistent if we not only switched over to the new versions for newbies but also had a nice upgrade path for old users. (Please correct me if we already do -- I simply haven't seen anyone publicize it.) I'm mostly interested in new installs, as they're the ones that get the nasty and inconsistent exim configuration script. -- see shy jo pgpxnSE8zz65P.pgp Description: PGP signature
Re: Bug#176506: Proposal seconded...though very late..:-)
Andreas Metzler wrote: I have not doublechecked packages.d.o. but the package's control file lists exim4, exim4-config, exim4-base and exim4-daemon-light as Priority: important and I cannot remember getting a mail about override disparities. It does have that priority, but debootstrap still installs exim, so the priority has no effect. -- see shy jo pgpy6dBBT6knP.pgp Description: PGP signature
Re: Policy for 32-bit uids/gids?
Colin Watson wrote: I'm slightly concerned by how we're going to map onto other systems' uses of 32-bit uids here, since there will already be some. 0-99 and 6-64999 were reasonably obvious back in the day, but I don't have a feel for how big systems are allocating uids now. I would be inclined to start allocating from near the top, although perhaps not right at the top to avoid 2^32-1. Perhaps we should reserve something like 2^32-2^24 to 2^32-2^16 (255 chunks) so that we have space for anything else that may turn out to need similar large block allocations. FWIW, I have a package that could use a block of about 1 thousand uids. Right now, it's, er, camping in the middle of the reserved block. I would like to see an initiative to agree this between multiple distributions via the LSB or similar with input from people running large systems, otherwise there'll probably be a horrible mess down the line. Good idea. -- see shy jo pgpP17MssttB7.pgp Description: PGP signature
Bug#197835: [PROPOSAL]: integrated environments are allowed
Chris Waters wrote: $PAGER is a different case. I might consider a proposal that $PAGER should only be used for terminal apps. That's historically how it's used for the most part, anyway. In fact, if we look around, I bet we'll find that most X apps ignore $PAGER, whether they're part of an integrated environment or not, and we should probably consider modifying policy to reflect reality here. But touch my $EDITOR at your peril! One problem with EDITOR and PAGER is that an X app has no way of knowing if the program is an X app, or if it must be run in a terminal. BROWSER of course avoids this by using a list of programs. I suspect that very few X apps really use EDITOR or PAGER at all, because of this flaw in the spec. -- see shy jo pgpqh8WWEQiqR.pgp Description: PGP signature
Bug#172436: followup on browser proposal
Ok, discussion turned up two problems, fixable by changing two words: Web browsers Some programs have the ability to launch a web browser to display an URL. Since there are lots of different web browsers available in the Debian distribution, the system administrator and each user should have the possibility to choose a preferred web browser. In addition, programs should choose a good default web browser if none is selected by the user or system administrator. | Thus, every program that launches a web browser with an URL should use the BROWSER environment variable to determine what browser the user wishes to use. The value of BROWSER may consist of a colon-separated series of browser command parts. These should be tried in order until one succeeds. Each command part may optionally contain the string %s; if it does, the URL to be viewed is substituted there. If a command part does not contain %s, the browser is to be launched as if the URL had been supplied as its first argument. The string %% must be substituted as a single % footnote This browser variable was proposed by Eric Raymond at http://www.tuxedo.org/~esr/BROWSER/ /footnote | If the BROWSER environment variable is not set, the program can use /usr/bin/x-www-browser if DISPLAY is set, and /usr/bin/www-browser if not. These two files are managed through the dpkg alternatives mechanism. Thus every package providing a general-purpose web browser must call the update-alternatives program to register the appopriate one of these alternatives. Instead of implementing the above in every program that runs a web browser, programs in Debian may be configured to use /usr/bin/sensible-browser . This is a program provided by the Debian base system that checks the BROWSER environment variable, and falls back to /usr/bin/x-www-browser or /usr/bin/www-browser if it is not set. In other words, we won't make BROWSER mandatory yet, since a few programs still need to implement it (I suspect gnome and kde are the most prominent that do not support BROWSER yet). And I have clarified the advice about how a program can work out a default browser to use, by avoiding a restricted word. I hope this is enough to get it seconded yet again, and into policy. -- see shy jo pgpdOtWQBL6b2.pgp Description: PGP signature
Bug#172436: followup on browser proposal
I just noticed, somewhat to my suprise, that this proposal is not in policy despite being fully implemented in debian now. Maybe it's because of Ian's reply. Ian writes: This is a bad idea because it will be very annoying if the URL is unfetchable - all the browsers will be launched in sequence. In practice BROWSER is set to a list two of browsers (mozilla:w3m) if someone wants to use one browser while in X, and another browser otherwise. In that fairly ususal case, you're used to the first, X-enabled browser failing part of the time, when there is no DISPLAY. If the url is bad, they both fail, which seems not too suprising. If someone sets BROWSER to something like w3m:lynx:links:wget then the first question is what on earth do they hope to achieve by doing this? Fall back to lynx is w3m cannot link today? It really doesn't make much sense. Again, when every command in the sequence fails, it's only doing what they requested, nonsensical as that was. How about we define an exit status which the command is required to give if it is not suitable for use at the moment ? sysexits.h isn't particularly helpful, but we could pick one of those. I would be happy to see this as a separate proposal, but someone else will need to make it. [ On the %s substitution stuff. ] I think this is a very bad idea. What if the URL maliciously contains shell metacharacters ? (I know they're not _supposed_ to.) The code in Debian already (see the sensible-browser program) does not let BROWSER touch a shell. If BROWSER contains a %s then the command is all parsed into words, substituted, and the browser execed. Just as Ian goes on to suggest we do, except we keep the %s available as the upstream BROWSER environment variable spec calls for, with no additional security issue. I think there was already a thread about this. The only possible security problem comes if some badly behaved program does this: system(sensible-browser 'url'); Such programs are broken, but it's breakage outside the scope of this proposal. I'd be happy to see someone make a proposal that programs not pass any kind of tainted data through the shell, ever, but someone else will need to work on that. :-) Every program I have converted to comply with the browser policy calls sensible-browser safely, using exec, or parses BROWSER on its own and runs the browser itself safely, using exec. The rest of Ian's mail suggests wording tweaks that I agree with. Here is a followup proposal that includes calling sensible-www-browser by its real name, sensible-browser. I've included change bars. I am looking for seconds, again. Web browsers Some programs have the ability to launch a web browser to display an URL. Since there are lots of different web browsers available in the Debian distribution, the system administrator and each user should have the possibility to choose a preferred web browser. In addition, programs should choose a good default web browser if none is selected by the user or system administrator. Thus, every program that launches a web browser with an URL must use the BROWSER environment variable to determine what browser the user wishes to use. The value of BROWSER may consist of a colon-separated series of browser command parts. These should be tried in order until one succeeds. Each command part may optionally contain the string %s; if it does, the URL to be viewed is substituted there. If a command part does not contain %s, the browser is to be launched as if the URL had been supplied as its first argument. The string %% must be substituted as a single % footnote This browser variable was proposed by Eric Raymond at http://www.tuxedo.org/~esr/BROWSER/ /footnote If the BROWSER environment variable is not set, the program should use | /usr/bin/x-www-browser if DISPLAY is set, and /usr/bin/www-browser if not. These two files are managed through the dpkg alternatives mechanism. Thus every package providing a general-purpose web browser must call the update-alternatives program to register the appopriate one of these alternatives. | Instead of implementing the above in every program that runs a web browser, | programs in Debian may be configured to use /usr/bin/sensible-browser . | This is a program provided by the Debian base system that checks the BROWSER environment variable, and falls back to /usr/bin/x-www-browser or /usr/bin/www-browser if it is not set. -- see shy jo pgpkgBqCTTPFJ.pgp Description: PGP signature
Bug#172436: followup on browser proposal
(Please restrict followups to the bug report, it's a PITA to have to go back and search debian-policy for discussion relating to a proposal.) Colin Walters wrote: If the BROWSER environment variable is not set, the program should use | /usr/bin/x-www-browser if DISPLAY is set, This, I have a big issue with. Let's say I have a multiuser system where I install GNOME and KDE. Now, suppose konqueror registers itself at a higher priority for this alternative for whatever random reason. Then whenver I'm in GNOME and click on a website, by default konqueror will be launched, which is broken. Likewise, if I'm in KDE, epiphany shouldn't be launched, at least by default. I hope I don't have to elaborate on the reasons why this is broken; it has been discussed in the past. This proposal is probably great for unintegrated environments, but some sort of exception should be made for integrated ones. You cut out the bit that says In addition, programs should choose a good default web browser if none is selected by the user or system administrator. I don't mind changing the program should use to the program can use, that was intended as advice, not a command. -- see shy jo pgpXoW2x6Yf1v.pgp Description: PGP signature
Re: Bug#172436: followup on browser proposal
This proposal is probably great for unintegrated environments, but some sort of exception should be made for integrated ones. The funny thing is that this proposal is just a reworking of section 12.4 of policy which deals with editors and pagers. If we have integrated environments in debian that would fall afoul of that particular wording for browsers, they probably would for editors and pagers too. It's amusing that nobody worried about that at all, while adding such integrated environments to Debian[1]. Maybe the maintainers of such environments should get policy fixed to explicitly allow for them in section 12.4 and elsewhere. Or perhaps we should just assume that the every program should choose a good default paragraph lets common sense be used here. -- see shy jo [1] Then again, the maintainers of such environments have historically disregared or badly implemented other important bits of policy, like 10.6. pgpjxyJUHWnY4.pgp Description: PGP signature
Re: libwww-curl-perl
Steve Kowalik wrote: At 8:49 pm, Monday, June 2 2003, Josip Rodin mumbled: I don't know exactly why it's done that way (it was introduced long before I ever became a Debian developer), but it's the scheme we use and we're keeping it, for consistency and backwards compatibility (we have almost 500 Perl modules packaged right now). Speaking of such, Perl and Java use the same scheme. But Python doesn't, which irks me. Surely liblinda-python would be more desirable rather than python-linda? The Debian perl module naming scheme is badly designed. On other discussions about this libwww-curl-perl thing, on debian-mentors and later debian-perl, someone pointed out that a perl module named C::Client would be libc-client-perl in Debian, which is horribly confusing. I'm glad that python is (mostly) using a more sane naming scheme. It's also rather useful to be able to type apt-get install python-tab and get python modules tab completed. The only thing the perl module naming scheme has going for it is inertia. I would like to see two things: - Policy proposal #114920 be accepted. This would give the maintainer of WWW::Curl for debian the leeway to use a more sane package name and only provide libwww-curl-perl. - Convert all perl module packages to use names like perl-foo-bar, after the next stable release. -- see shy jo pgpvSpmjALaii.pgp Description: PGP signature
menu-policy update process (Re: Bug#194974: [PROPOSAL] add Games/Simulation to menu subpolicy)
Chris Waters wrote: The whole point of keeping menu policy separate was so that it would be easy to modify without all the overhead of making formal policy changes. I'm a little perturbed that we seem to have lost that. Well, it's not clear from reading the various files in /usr/share/doc/debian-policy what the process for updating the menu-policy is supposed to be. I personally think that these types of things are better handled by having one person who just comes up with something logical and consistant. AFAIK it was split out of menu in the first place just so we didn't have to rev menu to change it. -- see shy jo pgpZ5Zfs5VcmR.pgp Description: PGP signature
Bug#194974: [PROPOSAL] add Games/Simulation to menu subpolicy
Bill Allombert wrote: There is a Games/Sports section defined as games derived from real world sports. I think csmash and gtkpool fit this criterium. I suppose. Then do we have enough simulations to warrant an Games/Simulation? The simulatian-ish things I find with a quick search are: - flightgear - atc and sail (bsdgames) (could go in Apps/Strategy just as well) - xlander (heh; in Games/Arcade already) - lincity (in Games/Simulation, could go in Games/Strategy with freecraft) - empire (well placed in Games/Strategy) - acm (in Games/Arcade, this is another flight sim, but more arcade-like) - sabre (another fighter plane sim, also in Games/Arcade) - pyddr (not really a simulation, Apps/Arcade is completly ok) - a lot of scientific and math sims that are fine in Apps/Science or Apps/Math and not germane to this discussion I guess this doesn't warrent a new section, but I don't know what do do with flightgrear. Maybe it should just be put in Games/Arcade. -- see shy jo pgpWtJsBmZ7QU.pgp Description: PGP signature
Re: amendment to shared library policy
Jack Howarth wrote: dh_shlibdeps should be performing a 'ldd -d -r' on each library in a package and issuing a warning if undefined symbols are detected. The warning issued by dh_shlibdeps should be simply that Additional linkage *may* be required for this shared library. You must mean lintian, debhelper is not in the business of sanity checking packages. -- see shy jo pgppGbJPZ1S5F.pgp Description: PGP signature
Re: Modernising menu manual icons requirement
Lars Wirzenius wrote: Indeed. With people using tiny laptops with 640x480 pixel screens to people using high-end workstations with two (or three?) multi-megapixel screens, there isn't any one size that will fit all. What Gnome, OS X, and KDE do is to provide icons in a large size that is then automatically scaled to the desired size. This doesn't provide for an optimal visual experience (an icon custom-designed for a given size is likely to be better than one resized), but the drop in quality is usually not that great, if the original icon is designed for this. Of course you'll get better results in such scaling if you have more colors available. The problem, I think, is that some of the window managers that support icons, like fvwm, do not do scaling, or don't do it very well. (Given that most people rarely see the icons in Debian-provided menus, and this includes me, I don't think a radical change in Debian's policy is needed, however.) Not sure I understand. Do you mean that you rarely see them because you use one of the window managers that does not display them, or because you turn them off, or because only 7% of menu entries[1] include an icon in the first place? Unless you mean something else, none of those seems like reason to keep things as they are, presumably some users use window managers that display them, don't turn them off, and see the low-quality, spottily available set of icons that we ship. The 7% figure is interesting. The typical leaf menu on my system has between 5 and 15 items in it. If the distribution of items that have icons is fairly random, most menus will have one or two icons on them, and the remainder of items with no icons. I have not checked this, but it seems rather nasty. I still think that dropping icons entirely and pushing the icons off into whatever desktop environments want to bother with them is a good approach. We might use some kind of hints, so that eg, the gnome menu[2] could know that a given program is a mail reader or web browser, and insert a generic icon if it doesn't have a specific one for that program. This could also allow someone to set up an 8-bit icons package if they really wanted to, or even a 2-bit set of icons. -- see shy jo [1] on my laptop [2] assuming it stopped treating the debian menu as a second-class add-on pgpmqaoUP0nqw.pgp Description: PGP signature
Re: Modernising menu manual icons requirement
David B Harris wrote: (Note that I'm subscribed to the list, no need to mail me personally.) On Tue, 13 May 2003 15:58:49 -0500 John Goerzen [EMAIL PROTECTED] wrote: On Tue, May 13, 2003 at 04:30:10PM -0400, David B Harris wrote: Instead of adjusting this to 48x48 to match current common practise, upping it to 128x128 will give us a bit more leeway. Why not just use SVG and eliminate the whole problem? Reality :) But 128x128 or SVG is fine. Tried scaling a 128x128 bitmapped icon to 32x32 lately? Ugh. -- see shy jo pgpuHwm1MMZjc.pgp Description: PGP signature
Re: Modernising menu manual icons requirement
Bill Allombert wrote: Here an extract from the menu manual: Debian package maintainers should ensure that any icons they include for use in the debian menus conform to the following points: 1. The icons should be in xpm format. 2. The icons may not be larger than 32x32 pixels, although smaller sizes are ok. 3. The icons should use only the 24 colors present in cmap.xpm, which comes with the `menu' package. 4. The background area of the icon should be transparent, if possible. Point 4 is beyond doubt. Point 1 is necessary since some window managers do not support other formats. Point 3 above seems a bit obsolete. 8-bit displays are rather exceptions currently, and some window managers include their own dithering routine that do a much better job that mogrify because they do it dynamically. Also a lot of menu icons do not comply to point 3, so I am not sure removing this requirement will really make things worse on 8-bit display. To accomodate with current workspace size, we could eventually change size in point 2 to 48x48. Opinions ? Funny, I was thinking about bringing this up just the other day. 8 bit displays are almost as uncommon today as 2 bit displays were when we adopted the icon policy. The exception might be high-end PDA's like the zarius, I don't know how many BPP they have, and folks do run Debian on them. PDA's aside, I think most systems with an 8 bit display are low-end pentium I or below, these are systems that only the desperate would try to run X on. The desperate can use any of the many window managers that don't bother with menu icons, or turn the icons off. This will probably improve their pentium I experience. :-) icon size and screen resolution continues to be all over the map from what I can see, with 1024x768 still nearly as common as it was when we decided on 32x32, and smaller screens still common between PDAs and various subnotebooks. There is perhaps a tendancy toward larger icons (non-menu) in programs like window maker, with a corresponding offset in that kde and gnome seem to use 16x16 icons from what I can remember. (I use ion, which does not have menus, or icons, so please correct me..) Finally, I have never been happy with the icons provided by debian. There are not enough of them, they are inconsistant in style, and the low resolution and limited colors make them look like escapees from 1989. I have turned off icons on every window manager I've used (that supported them) from a few weeks after menu began to support icons. Perhaps we would be better off to let the desktop projects that have dedicated teams and a set style and target (like KDE and Gnome) worry about the menu icons, and simply not provide any. -- see shy jo pgp6j68fUTAuw.pgp Description: PGP signature
Re: policy should frown on programs in PATH with language extentions (ie, .pl)
Richard Braakman wrote: On Tue, Apr 22, 2003 at 10:03:44PM +0200, Bill Allombert wrote: I would personnally be fine with only: When scripts are installed into into a directory in the system PATH, the script name should not include an extension such as .sh or .pl that denotes the scripting language currently used to implement it. but I can easily be persuaded otherwise. I'd like a just or simply before the denotes, otherwise we'll get cheeky people arguing that naming a perl script doit.sh is just fine :) I don't think either suggested word would restrain such a wise-alec, and it's probably not worth bloating policy with an airtight definition. Commen sense should serve.. (But then, if it did, I'd maybe not be proposing this..) -- see shy jo pgpQMmAWaqgAA.pgp Description: PGP signature
Re: policy should frown on programs in PATH with language extentions (ie, .pl)
Bill Allombert wrote: I would second it, but I do not like the wording: When scripts are installed into /usr/bin or other directories in the PATH why not: into a directory in the system PATH, I don't see much benefit either way. Reads the same to me. There may be rare exceptions to this rule, and this does not apply to scripts in /usr/share or to example scripts in /usr/share/doc/*/examples. What kind of exception do you have in mind ? Remember, we are only against an extension such as .sh or .pl that denotes the scripting language currently used to implement it. Random extension for other purpose are still OK (e.g. versionning, alternatives, backup, etc...). (python2.1,mkfs.ext2, xdvi.real,updatedb.notslocate, pstree.x11) I had in mind the i2e program, which is shipped upstream as i2e, a graphical binary, and i2e.sh, a command-line tool. Granted this is annoying, and I've already asked the maintainer to ask upstream to find a better name than i2e.sh, but it probably shouldn't be forced to change by policy. Also, I like leaving room for weird stuff in general. does not apply to scripts in /usr/share or to example scripts in /usr/share/doc/*/examples. I think this is covered by the first sentence. Sure, that could be removed. I thing the two situations when the language extension is useful is 1) when the script is sourced rather than exec'ed and 2) if it is a config file. I agree. I don't think it's good design to put a program name into a config file. sysvinit's use of .sh scripts is fine of course. If the script is not in the PATH and never to be used by the user, the language extension serve no purpose but do no harm. Yep. I would personnally be fine with only: When scripts are installed into into a directory in the system PATH, the script name should not include an extension such as .sh or .pl that denotes the scripting language currently used to implement it. but I can easily be persuaded otherwise. I would also be happy with this, and I'll file a bug with a proposal now that it's had at least some discussion. -- see shy jo pgpDooDBf8nxN.pgp Description: PGP signature
Bug#190753: [PROPOSAL] frown on programs in PATH with language extentions
Package: debian-policy Version: 3.5.9.0 Severity: wishlist I suggest we add the following to policy section 11.4. (Wording by Bill Allombert.) When scripts are installed into into a directory in the system PATH, the script name should not include an extension such as .sh or .pl that denotes the scripting language currently used to implement it. This was previously discussed on the thread entited policy should frown on programs in PATH with language extentions (ie, .pl) on the debian-policy list. I will leave off the full rationalle, which is in the first message of that thread. The short version is that using this sort of name seems to be becoming more prevelant, and that it asks for problems when a program is reimplemented, and makes it harder to type command names. I am looking for seconds to this proposal. -- see shy jo pgpUrLyvPgzAs.pgp Description: PGP signature
policy should frown on programs in PATH with language extentions (ie, .pl)
There seem to be more and more packages that are dumping programs into /usr/bin or elsewhere and givning them names with end in .pl, .sh, .py, .tcl. etc. I hadn't realized exactly how many there were until I looked through a ls /usr/bin/*.* on my system, and found almost a dozen, like these: /usr/bin/abw2html.pl /usr/bin/bbkeysconf.pl /usr/bin/cm2rem.tcl /usr/bin/collateindex.pl /usr/bin/dpkg-checkdeps.rb /usr/bin/dpkg.rb [ possibly a special case ] /usr/bin/i2e.sh [ somewhat of a special case ] /usr/bin/ttfadmin.sh /usr/bin/wkdemenu.pl I'll bet that most of these are things that were included in an upstream tarball as examples or one-use scripts or what have you and were not really expected to be slapped into /usr/bin. Just look at the number of similarly named programs in the examples directory -- which is fine of course. It's fine too that the maintainers of these packages chose to put the programs in /usr/bin, but I think they should take the time to make them look like regular unix programs, by removing the extensions when they do. I have filed bug reports on most of the above, and on various other programs like these in the past. I think that this is a bad path for us to be going down, for some obvious reasons: - What if the implementation languages changes? - Why should a user care what the implementation language is? - It looks unprofessional and flies in the face of unix tradition. - It's harder to type. (See also bug #189304.) There may already be enough packages doing this, or enough special cases (like i2e.sh, which complements an i2e program but could still stand to be renamed, or dpkg.rb which I don't really know why is in /usr/bin, but obviously cannot be called just dpkg) so that policy cannot outright prohibit the practice, but I feel it should discourage it, and the vast body of scripts in PATH in Debian do not use this naming strategy after all. I suggest something like this be added to section 11.4: When scripts are installed into /usr/bin or other directories in the PATH, the program name should not include an extension such as .sh or .pl that denotes the scripting language currently used to implement it. There may be rare exceptions to this rule, and this does not apply to scripts in /usr/share or to example scripts in /usr/share/doc/*/examples. -- see shy jo pgp3ux74Wm5CL.pgp Description: PGP signature
noisy maintainer scripts
I thought that policy used to have something to say about over-noisy maintainer scripts along the lines of leave the progress reporting to dpkg, but I cannot find it. Was this lost in a reorg? -- see shy jo pgp6rXYqKlrEq.pgp Description: PGP signature
Bug#185364: debian-policy: project url's should be required for each apt-cache package description
Dan Jacobson wrote: Anyway, here's a typical case. $ apt-cache show flightgear ... Description: Flight Gear Flight Simulator Flight Gear is a free and highly sophisticated flight simulator. . This package contains the runtime binaries. This description sucks. Adding an url to it will *not* fix it. If the description talked about what kinds of features there were, what sorts of planes you could fly, what scenarios, airports, courses, or whatever there were, what kind of graphics card you needed, etc, etc, you should not need the upstream url to decide if you wanted to install it, unless perhaps you needed a screenshot to decide (seems unlikely for something like a flight simulator, a static picture of sky and instruments cannot capture the program). The thing I really worry about with promoting urls in descriptions is that they will come to substitute for good descriptions. Which will make it far harder to find a package, even if you happen to have a net connection at the time. This is why I can back proposals for fields that link directly to a screenshot, and why I feel very iffy about general urls. -- see shy jo pgpachCwLJcQP.pgp Description: PGP signature
Bug#185364: debian-policy: project url's should be required for each apt-cache package description
Colin Watson wrote: I object. It's a waste of considerable effort to go around adding This package has no upstream URL to several thousand packages. I think we've already informally agreed that having upstream URLs in package descriptions [1] where packages.debian.org can see them is a good thing; policy doesn't need to change here, packages can just go right ahead and do it in cases where it is appropriate. I agree. [1] Discounting the argument about whether a new field should be added, for the sake of brevity. Well, rats! :-) That's the interesting bit and the bit policy could do something about. -- see shy jo pgpYv2ycV0aXk.pgp Description: PGP signature
Bug#184064: debian-policy: [PROPOSAL] Every window manager should provide an alternative to the x-window-manager.1 manpage
Jerome Marant wrote: I've sent a patch for Debhelper (See #85963) but it won't be applied as long as Policy don't say so. When did I say that? I am still unhappy with the implementation in debhelper, is all. (Modify policy to get rid of the /usr/X11R6/man/ tree, and I would be able to implement it much easier..) -- see shy jo pgpblsx8BHge3.pgp Description: PGP signature
Bug#184064: debian-policy: [PROPOSAL] Every window manager should provide an alternative to the x-window-manager.1 manpage
Josip Rodin wrote: Think harder. :) A user runs man x-window-manager once, sees something, later the alternative gets changes to another WM for whatever reason, they run man x-window-manager again, see another thing, confusion ensues. editor(1) and pager(1) and www-browser(1) are already provided by at least some apternatives for those programs. If this is really a problem, which I don't think it is. Instead I think that slave links for alternatives is common practice, and I have seen no confused users because of it. -- see shy jo pgpmBfs6zHuoj.pgp Description: PGP signature
Bug#184064: debian-policy: [PROPOSAL] Every window manager should provide an alternative to the x-window-manager.1 manpage
Jérôme Marant wrote: Joey Hess [EMAIL PROTECTED] writes: Jerome Marant wrote: I've sent a patch for Debhelper (See #85963) but it won't be applied as long as Policy don't say so. When did I say that? I am still unhappy with the implementation in debhelper, is all. (Modify policy to get rid of the /usr/X11R6/man/ tree, and I would be able to implement it much easier..) I may have misinterpreted this from you (see the bug report I mentioned) : I'd appreciate a patch. I really need to re-read the policy for window managers, I'm not up to date on the requirements. Yes, but I had more to say a bit later in that bug report. Consider me fairly up-to-date on window manager policy now. -- see shy jo pgpUoLkOYws75.pgp Description: PGP signature
Bug#184064: debian-policy: [PROPOSAL] Every window manager should provide an alternative to the x-window-manager.1 manpage
Jérôme Marant wrote: Joey Hess [EMAIL PROTECTED] writes: Josip Rodin wrote: Think harder. :) A user runs man x-window-manager once, sees something, later the alternative gets changes to another WM for whatever reason, they run man x-window-manager again, see another thing, confusion ensues. editor(1) and pager(1) and www-browser(1) are already provided by at least some apternatives for those programs. If this is really a problem, which I don't think it is. Instead I think that slave links for alternatives is common practice, and I have seen no confused users because of it. So, would you second my proposal? Well, I note that none of editor(1), pager(1), or www-browser(1) are mentioned in policy at all. I might second a proposal to document them in policy and add x-window-manager(1) too. -- see shy jo pgppysl6FrY8n.pgp Description: PGP signature
Re: Privacy concern with debconf
James Blanford wrote: I am concerned with a new trend that uses debconf to configure personal information into system files. I'll start with an exaggerated example. I have a Window Maker dockapp, wmbday, that counts down the seconds to my birthday and then displays the message, Happy Birthday, Yournamehere!. If I installed it the way some dockapps do it now, debconf would ask for my name and birth date and put that info in command line parameters in the /usr/lib/menu/wmbday file. Now even legitimate users of the program have access to my personal information, not to mention that it is also possible for any user, daemon or hacker to read the info from this world readable file. The real packages I'm talking about are wmweather and wmmoonclock. The former stores your METAR (local weather station) code in /usr/lib/menu/wmweather and the latter stores your latitude and longitude. These are not big concerns for me, but it's not hard to imagine some person or some organization that wouldn't want this info to be exposed. I doubt these programs should be modifying /usr like that. Conffiles belong in /etc, generated files in /var. Worth a bug report on the FHS violations alone. It also seems to me it would be better to let these programs read a dotfile in $HOME, with perhaps an interactive GUI congfigurator that they can bring up, and not have a site-wide configuration for them at all. But I don't grok the privacy concerns: If you have users on your local machine from whom you want to hide the location of your machine, you have bigger problems than METAR. The time zone and routing table of your machine come to mind, and I am sure there is much more. But, all such data should be in /etc and /var where admins can find if if they are really trying to lock down a machine in this manner. That's where the FHS comes in. I could find no Debian guideline on this matter. Certainly one could define the difference between configuration that changes how a program runs and configuration that personalizes the program for a specific user. Right, I think it's a well-estblished conventon that the former goes in /etc and the latter in $HOME. -- see shy jo pgpTboN6a3L5w.pgp Description: PGP signature
Bug#181923: refers reader to itself
Package: debian-policy Version: 3.5.8.0 Severity: normal D.2.9. `Section' and `Priority': See the Debian policy manual for the priorities in use and the criteria for selecting the priority for a Debian package Heh. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux dragon 2.4.20 #1 Thu Feb 20 11:25:25 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C -- no debconf information -- see shy jo pgp7N0N4N5xA2.pgp Description: PGP signature
Re: Question regarding policy (11.2)
Josip Rodin wrote: And you are totally ignoring what I wrote in my initial mail! I'm sure your mail was the most important post on the thread and stuff, but - a) I am catching up from a 40 thousand message, 1 month backlog, and frankly whatever you said didn't really stick in my mind. b) I didn't respond to it, I responded to emails that seemed to seriously be advocating doubling the number of -dev packages in debian. In particular, I responded to this statement by Jamin W. Collins: On Fri, Feb 07, 2003 at 10:22:38PM -0800, Brian Nelson wrote: Err, sorry. I was under the impression that Jamin supported moving *all* static libraries to separate packages (the worst case scenario as James said). Maybe I misunderstood him. I do support such a move. It increases the options available. If I had specific arguments with your post, I suppose I would have responded directly to it when I read it. Perhaps this insight into my email habits will cut down on pointless flaming in the furture. Anyway this thread is going nowhere, why don't you make a concrete formal policy proposal or something. -- see shy jo pgp0WXZ8pAS4v.pgp Description: PGP signature
Re: Question regarding policy (11.2)
Josip Rodin wrote: On Sat, Feb 08, 2003 at 07:15:52PM -0500, Joey Hess wrote: Adding 1100 additional packages to debian This tendency to fuck up a discussion, despite my best efforts to talk about a compromise right from the start, is very frustrating. % grep-available -F Package -r 'lib.*[0-9]$' -s Package -n | wc -l 768 Shall we please return to constructive discussion now, as opposed to these repeated cantankerous litanies? I don't see where you're coming off with the personal abuse. If I have a history of participating in unfounded, repeated, cantankerous litanies on this list, I would at least appreciate some examples of threads where I have behaved in such a manner. I also don't see why your method of counting -dev packages is any more accurate then mine.. It's the high and the low estimate, and even your low estimate would add 600 kb to the Packages file. -- see shy jo
Re: Question regarding policy (11.2)
Jamin W. Collins wrote: Would moving the static libraries to separate packages increase the number of package in Debian, certainly. Would this be bloat, I don't see it as such. To consider this as bloat is to consider the choice of editors available in Debian (~100+ according to a quick apt-cache search) to be bloat. They are not. Will every user use them, no. However, they provide choice. Adding 1100 additional packages to debian, and 800 mb[1] additional to be downloaded every apt update is unambiguously bloat. It also goes rather against the originally stated rationalle of saving on download time. And it wouldn't provide any significant choice. -- see shy jo [1] [EMAIL PROTECTED]:~grep-available -F package -- -dev list [EMAIL PROTECTED]:~ls -l list -rw-rw-r--1 joey joey 843948 Feb 8 19:13 list pgpfzF6soacGd.pgp Description: PGP signature
Re: Question regarding policy (11.2)
Joey Hess wrote: Jamin W. Collins wrote: Would moving the static libraries to separate packages increase the number of package in Debian, certainly. Would this be bloat, I don't see it as such. To consider this as bloat is to consider the choice of editors available in Debian (~100+ according to a quick apt-cache search) to be bloat. They are not. Will every user use them, no. However, they provide choice. Adding 1100 additional packages to debian, and 800 mb[1] additional to be Er um, kilobytes of course. -rw-rw-r--1 joey joey 843948 Feb 8 19:13 list -- see shy jo pgpcnxekznxgO.pgp Description: PGP signature
Re: mailing lists as maintainer address
Anand Kumria wrote: What is the opinion of this group? [EMAIL PROTECTED]:~dpkg -p debian-policy Package: debian-policy Priority: optional Section: doc Installed-Size: 1448 Maintainer: Debian Policy List debian-policy@lists.debian.org -- see shy jo pgpYYjt8oNGrQ.pgp Description: PGP signature
Bug#172436: correction
The policy text needs to have sensible-www-browser replaced with sensible-browser, which is the real name of the program in debianutils. -- see shy jo pgpjGcd8WlILV.pgp Description: PGP signature
Re: [devel-ref] author/homepage in description
James R. Van Zandt wrote: I think the link in the copyright file to the upstream sources should be in a standardized, parsable format. Likewise the author name. That way lintian could check for them. The last time I checked, 5 or 10 percent of our packages lacked any link to the upstream sources. Then, it would make sense to add a link to the project home page in the same place. That would not impact the Packages files. If you want a parseable link to the upstream source, use uscan files. Of course maybe 10% of all packages have them, but they're perfect for the job (and anyone who doesn't have one should add one). This is rather different than homepage links though. -- see shy jo pgpdYMPpOAMhp.pgp Description: PGP signature
Bug#172436: debian-policy: [PROPOSAL] web browser url viewing
Package: debian-policy Version: 3.5.8.0 Severity: normal As discussed earlier on this list, and now implemented by lots of stuff in Debian[2] and with only a few to go[3], I'm proposing that the following be added to policy around section 12.4: Web browsers Some programs have the ability to launch a web browser to display an URL. Since there are lots of different web browsers available in the Debian distribution, the system administrator and each user should have the possibility to choose a preferred web browser. In addition, programs should choose a good default web browser if none is selected by the user or system administrator. Thus, every program that launches a web browser with an URL must use the BROWSER environment variable to determine what browser the user wishes to use. The value of BROWSER may consist of a colon-separated series of browser command parts. These should be tried in order until one succeeds. Each command part may optionally contain the string %s; if it does, the URL to be viewed is substituted there. If a command part does not contain %s, the browser is to be launched as if the URL had been supplied as its first argument. The string %% must be substituted as a single % footnote This browser variable was proposed by Eric Raymond at http://www.tuxedo.org/~esr/BROWSER/ /footnote If the BROWSER environment variable is not set, the program should use /usr/bin/x-www-browser if there is an available X Window System DISPLAY, and /usr/bin/www-browser if not. These two files are managed through the dpkg alternatives mechanism. Thus every package providing a general-purpose web browser must call the update-alternatives program to register the appopriate one of these alternatives. If it is very hard to adapt a program to make use of the BROWSER variable, that program may be configured to use /usr/bin/sensible-www-browser instead. This is a program provided by the Debian base system that checks the BROWSER environment variable, and falls back to /usr/bin/x-www-browser or /usr/bin/www-browser if it is not set. I'm looking for seconds. If you seconded the earlier, informal proposal, please re-second this formal one. -- see shy jo [1] sensible-browser http://lists.debian.org/debian-policy/2002/debian-policy-200211/msg00189.html [2] debianutils, links, mozilla, urlview, w3m, xchat, xpdf [3] lynx has a patch in the BTS; konqeror is patched in CVS pending new release; any other unmentioned web browsers still need updates as do probably still tons of packages that hardcode calls to netscape. Find something and I'll gladly patch iT. pgpcbVaP98IRy.pgp Description: PGP signature
Re: [devel-ref] author/homepage in description
Adam DiCarlo wrote: Huh. I'll have to play around with this. I would indeed rather use a field, even a custom field, if possible, since this is really data. I'm hearing just go with homepage only, no other data really needed. I'll make that change. The point was validly raised in a previous thread that using these means changing packages twice in the event that dpkg is eventually changed. That I don't follow. The only nice thing about using the description is that it is already supported by packages.debian.org, whereas a custom field would obviously not be supported there. Colin's point is that if a lot of us modify our control files to use XB-Homepage or whatever, and then Homepage goes into policy as a truely supported field, then we all have to go back and remove the XB- from our control files. I think the best way to go ahead is get the field added to dpkg, then we can just start using it and go from there. The policy group prefers to document things that are already in use these days I understand. The dpkg maintainers have to be convinced to add it is all. In the meantime, anyone who doesn't mind revving a package later can get a jump on things with the XB- technique. If we can agree on a field name. While I've seen examples of Upstream-URL, Upstream-Homepage, etc., I'm partial to just Homepage. It indicates clearly that it is a web page, and it indicates what page the url is supposed to point to. It's also a term any use who sees it will immediatly understand. The Upstream seems redundant. Get a couple hundred packages using the field consistently and it'll really take care of itself. -- see shy jo pgpAxwsPAlabD.pgp Description: PGP signature
Re: [devel-ref] author/homepage in description
Denis Barbier wrote: For translators having a development URL is also useful, because they can then send up to date translations; it was said that it is then available from package homepage, but some packages have no homepage and have a public CVS repository. I'm not sure what a development URL is. You cannot really give an url directly to a cvs repository and surely it'd not be world readable anyway. It would also be very helpful to know when packages have upstream translation teams, e.g. in GNU, GNOME or KDE projects, so that Debian translators do not interfere with their work. IMO a Project field is enough, its value being either some known values or an URL. Last point, it is frustrating to work on translations which are never incorporated. For instance if you do not want to bother with the FSF disclaimer, you might want to know whether an author mandates it or not. I guess I don't see any of these things being worth bloating Packages files with. You don't need them at install time; the info is probably not even needed in binary packages. If a translator needs the source package anyway to do translation work, such info could just be present in there. If you want to spec out a file that goes in source packages for this kind of structured data, fine. uscan files are a good example of something similar. -- see shy jo pgpXZWd6hjzSW.pgp Description: PGP signature
Re: [devel-ref] author/homepage in description
Britton wrote: I don't like this. The pages listed will end up being wrong half the time and google can find homepages very well and everybody knows it, so what is the point in adding this? Well we already have the links in the copyright files now, so if they're going to be wrong half the time that must already be a problem. I'd hope most maintainers are tuned in well enough to upstream development of their package to notice when its url changes. -- see shy jo pgp7U32zLyoUc.pgp Description: PGP signature
Bug#172022: FWD: Re: description writing guide
Josip Rodin wrote: On Fri, Dec 06, 2002 at 12:33:06PM -0500, Joey Hess wrote: Package: debian-policy The dropping of the packaging manual seems increasinly hasty and ill-thought-out, when important documentation like this turns out to have been dropped from debian in the process. Get your facts straight before casting accusations like that. Many important things from that text are in Policy section 5.7. Er, I was there at the time, and IIRC protested the dropping of the Manual at the time. Section 5.7 does not have any documentation about the format of the description field. -- see shy jo pgpQ9EuofUQ69.pgp Description: PGP signature
Bug#172022: FWD: Re: description writing guide
Josip Rodin wrote: How about the attached patch? Looks good to me. -- see shy jo pgp42gc2sLVVN.pgp Description: PGP signature
Bug#172022: FWD: Re: description writing guide
Package: debian-policy The dropping of the packaging manual seems increasinly hasty and ill-thought-out, when important documentation like this turns out to have been dropped from debian in the process. This should probably go into the policy manual's appendices. - Forwarded message from John Hasler [EMAIL PROTECTED] - From: John Hasler [EMAIL PROTECTED] Date: 05 Dec 2002 18:21:01 -0600 To: debian-devel@lists.debian.org Subject: Re: description writing guide X-Spam-Status: No, hits=-12.6 required=5.0 tests=AWL,IN_REP_TO,MAILTO_TO_SPAM_ADDR,REFERENCES, SIGNATURE_LONG_SPARSE,SPAM_PHRASE_03_05,USER_AGENT,X_LOOP, X_MAILING_LIST version=2.41 David B Harris writes: Could you point me at the documentation in question? Debian Packaging Manual --- Ian Jackson [EMAIL PROTECTED] Revised: David A. Morris [EMAIL PROTECTED] Maintainer: Christian Schwarz [EMAIL PROTECTED] Maintainer: Manoj Srivastava [EMAIL PROTECTED] Maintainer: The Debian Policy group debian-policy@lists.debian.org version 3.1.1.1, 1999-11-22 ... ... ... 7. Descriptions of packages - the `Description' field - The `Description' control file field is used by `dselect' when the user is selecting which packages to install and by `dpkg' when it displays information about the status of packages and so forth. It is included on the FTP site in the `Packages' files, and may also be used by the Debian WWW pages. The description is intended to describe the program to a user who has never met it before so that they know whether they want to install it. It should also give information about the significant dependencies and conflicts between this package and others, so that the user knows why these dependencies and conflicts have been declared. The field's format is as follows: Description: single line synopsis extended description over several lines The synopsis is often printed in lists of packages and so forth, and should be as informative as possible. Every package should also have an extended description. 7.1. Types of formatting line in the extended description - * Those starting with a single space are part of a paragraph. Successive lines of this form will be word-wrapped when displayed. The leading space will usually be stripped off. * Those starting with two or more spaces. These will be displayed verbatim. If the display cannot be panned horizontally the displaying program will linewrap them `hard' (ie, without taking account of word breaks). If it can they will be allowed to trail off to the right. None, one or two initial spaces may be deleted, but the number of spaces deleted from each line will be the same (so that you can have indenting work correctly, for example). * Those containing a single space followed by a single full stop character. These are rendered as blank lines. This is the _only_ way to get a blank line - see below. * Those containing a space, a full stop and some more characters. These are for future expansion. Do not use them. 7.2. Notes about writing descriptions - _Always_ start extended description lines with at least one whitespace character. Fields in the control file and in the Packages file are separated by field names starting in the first column, just as message header fields are in RFC822. Forgetting the whitespace will cause `dpkg-deb' [1] to produce a syntax error when trying to build the package. If you force it to build anyway `dpkg' will refuse to install the resulting mess. [1] Version 0.93.23 or later. _Do not_ include any completely _empty_ lines. These separate different records in the Packages file and different packages in the `debian/control' file, and are forbidden in package control files. See the previous paragraph for what happens if you get this wrong. The single line synopsis should be kept brief - certainly under 80 characters. `dselect' displays between 25 and 49 characters without panning if you're using an 80-column terminal, depending on what display options are in effect. Do not include the package name in the synopsis line. The display software knows how to display this already, and you do not need to state it. Remember that in many situations the user may only see the synopsis line - make it as informative as you can. The extended description should
Re: Debian-Perl-Policy and .packlist?
Michael Lamertz wrote: I was wandering for a while now why the ExtUtils::Installed module that comes with perl-modules doesn't work. Some days ago I noticed the Debian-Perl-Policy which says: .packlist files should not be installed. There's no reason given why this is policy, but it breaks the functionality of perls legal way to test the runtime environment, and I don't think that this is a Good Thing (tm). Is there anything one can do about that? Don't .packlist files get added to if another module is installed in the same subdirectory? It's been a while since I looked at them, but that would make it incompatable with our packaging system. You'll probably have better luck with this question on debian-perl, so I am ccing there. -- see shy jo pgpKYXXyM8QmI.pgp Description: PGP signature
Re: web browser url viewing proposal
Lukas Geyer wrote: Fully seconded. (In the sense of implementing this mechanism, fixing the affected packages and finally making it policy.) This is especially helpful when packaging programs having an extensive manual in HTML and some Help button in their menu. It hit me when I was trying to package euler, which defaults to calling netscape. (Now someone else packaged it before me and did not bother to look for a sensible solution...) Yes, that's the very common case that I forgot to mention of course. I suppose I'll wait a day or two and then we can begin by starting to send out bugs with patches to the various brosers and browser-using programs. -- see shy jo pgpEqbrnJBZHs.pgp Description: PGP signature
Unidentified subject!
Colin Watson wrote:
Seconded, with one proviso: can we standardize on the Compatible Secure
BROWSER Definition from
http://www.dwheeler.com/browse/secure_browser.html instead? This is what
man-db implements for the 'man -H' switch; ESR-style BROWSER variables
will still work as intended, but %c is added in order to permit a colon
in commands and it specifies what shell escaping is to be performed on
URLs to get rid of the hideous security flaws.
I assume you mean the compatible alternative and not the bare one
(though there's something to be said for the bare one; wrappers are not
hard to write).
First of all, it's possible to write a program that uses ESR's BROWSER
without passing the url through the shell. Here is a modification of my
sensible-browser program that does that:
--- sensible-browser~ 2002-11-19 12:20:14.0 -0500
+++ sensible-browser2002-11-19 12:20:31.0 -0500
@@ -11,7 +11,7 @@
else {
$_.=' '.$url;
}
- exec $_;
+ exec split ' ', $_;
# on failure, continue to next in list
}
Before:
[EMAIL PROTECTED]:~BROWSER='echo' ./sensible-browser 'http://;echo rm -rf /'
http://
rm -rf /
After:
[EMAIL PROTECTED]:~BROWSER='echo' ./sensible-browser 'http://;echo rm -rf /'
http://;echo rm -rf /
So is the increased complexity of making %s be converted to an escaped
absolute reference worth it? I note that the definition of escaped
absolute reference uses a hardcoded list of shell metacharacters to
escape. Such lists are often incomplete, I've seen exploits on bugtraq
of this kind of thing in the past. It seems easier to just program
defensively, not pull the shell into the picture, and not worry about
escaping.
The secure browser page does mention wanting to pass the BROWSER command
through the shell for backwards compatability (with what one wonders)
and to allow complicated shell expressions in BROWSER. I think that's a
bit of a non-starter; if you need something complicated you can
certianly write an external script. The complexity outweighs the gain.
How about we just add something like this to the proposal:
When implementing BROWSER in a program, be careful to not pass the URL
through the shell when running the browser commands, as the url might
contain shell metacharacters and there could be security problems. If
you must pass the URL through the shell, be careful to properly escape
it first.
--
see shy jo
pgpVtLxhnP83E.pgp
Description: PGP signature
Re: web browser url viewing proposal
Joey Hess wrote: First of all, it's possible to write a program that uses ESR's BROWSER without passing the url through the shell. Here is a modification of my sensible-browser program that does that: And I have a patch for urlview now, based on ESR's, that while using system, quotes the url properly even if calling BROWSER, and is also shell-safe. It's really not hard. -- see shy jo pgp9qKY2RNmK8.pgp Description: PGP signature
Re: web browser url viewing proposal
Massimo Dal Zotto wrote: I propose also that sensible-browser is registered as preferred or only handler for text/html and other url mime types. This can obviously be overriden in personal mailcap files but the debian alternative and the BROWSER variable should be the preferred control it. I'm not sure about this. It *would* be nice to have BROWSER contol mailcap, but perhaps some browsers would want to set up mailcap files with more complex tests specific to them. Perhaps we should discuss this separatly to the main proposal after it gets in. In addition, programs should choose a good default web browser if none is selected by the user or system administrator. This should be done in a centralized way by sensible-browser. Other programs should call only sensible-browser, unless they require some specific browser. If none selects a good default the x-www-browser alternative should do it. Thus, every program that launches a web browser with an URL must use the BROWSER environment variable to determine what browser the user wishes to use. Again, why not just call sensible-browser? A program needing a browser should simply depend on debianutils and www-browser|x-www-browser. Parsing the BROWSER variable and substituting the url value in the proper way in every program seems to me an unnecessary duplication of code. It often may be, and in those cases programs can of course just run the sensible-browser script. On the other hand, they may well want more control over what browser is picked as a fallback if BROWSER is not set or if none of the items in that variable are usable. Or they might want to implement it without a fork for speed, or what have you. It seems best to offer the flexability. Anyway, it paralells completly how the editor and pager stuff works. Colin has a good point too. An update on my patching: I have patches for: lynx w3m links debianutils urlview xchat I won't be messing with mozilla or konqueror, as they are too large, and the necessary changes too trivial. I'll just file wishlist bugs on those. Since I just noticed that xpdf has url support (which never worked, because I don't have bloody netscape installed. Argh!!), I'll be patching it too. I think that's all for me. It would be amusing to grep the whole main distro for things that hardcode netscape. Grepping your own /etc for netscape will also show some things to patch. -- see shy jo pgpc5DhvDvL2Z.pgp Description: PGP signature
