Bug#685039: developers-reference: please document what is needed to reintroduce a package
On Thu, Aug 16, 2012 at 08:42:45AM +0800, Paul Wise wrote: +You should check why the package was removed in the first place. This +information can be found in the removal item in the news section of the PTS +page for the package or by browsing the log of +ulink url=http://ftp-master-host;/removals.html;removals/ulink. Perhaps there should be a note making clear that only removal from unstable (and experimental) is what is meant here; removals from testing do not give cause to use this procedure. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Goswin Brederlow wrote: Two new fields are introduced: Build-Depends-Arch, Build-Conflicts-Arch You are aware, I hope, that the original proposal for the Build-* fields contained these fields, and they were dropped from the proposal after several people (buildd admins, if I recall correctly) indicated that they are useless in practice. I recommend reviewing the discussion and addressing their arguments in this proposal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: build-depends-indep and arch: all source packages
On 20030903T212419+0200, 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. So, build-depends-indep
were created, so that those build-dependencies that aren't needed to
autobuild a arch-dependent package can be put in there, and autobuilders
don't waste time and diskspace installing packages they don't need.
To set the history straight...
When I proposed the build-time dependency system, I had a complete set
of Build-{Depends,Conflicts}{-Arch,Indep,} (with a different naming
convention, but who cares:). The consensus from the discussion was that
Build-{Depends,Conflicts}-Arch are unnecessary and so they were not
adopted. However, Build-Depends-Indep has been in Policy as long as
Build-Depends.
--
Antti-Juhani Kaijanaho, Debian developer http://www.iki.fi/gaia/
pgpBOO1lmOYET.pgp
Description: PGP signature
Re: Software Licenced Under a Specific Version of GPL
On 20010830T141556-0500, Manoj Srivastava wrote: Yes, it would, since we would be violating the terms of the packages that do _not_ want later versions; and if people in charge of policy when GPL v3 comes out do not take care of this, they shall be screwing up. Actually, I think the screwup has already been done: we don't specify which version of GPL the common-licenses file contains. Whatever we do to fix that, it breaks something (letting the GPL file be version 2 always breaks aesthetics. which is minor breakage but breakage nonetheless). I, however, have full faith in our succesors, and I am not going to assume they shall just follow the masses and the hell with the details philosophy. I am cynical: I don't expect our successors to be any better than we are now. We make mistakes, they will make mistakes. In my experience, this philosophy is quite useful in software development. Anyway, we are straying from the point. Antti-Juhani I don't think so - look at what we did to LGPL. Point taken. We4 did screw up, unless someone already has taken steps to look at the LGPL licences and fix all those who did not want later versions. Are you sure this step was not taken? No I don't, but I cannot recall any steps having been taken at that time. Quick grepping did not find any packages that are broken in this way (but lots of packages that, for example, neglect to specify a version at all). Can you point me to any instances where the symlink causes us to mis represent any package? Not at this time; but I'm leaving for a work-related trip in fifteen minutes, and do not have the time to do a comprehensive search. I'll return to this on Monday. If they do what Ari fears, it shall be a screw up -- we should not mis represent licenses, and we should not point people to licenses that do not conform to what the upstream author intends the license to be. Are you implying that sdhall not be a screw up? No. It seems I wrote complete gibberish there :-) Please file a wish list bug against the relevant package. The policy group does not have objections to using that symlink if it is created? (Note that policy only refers to GPL and LGPL, not to GPL-2 or LGPL-2.) -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: Software Licenced Under a Specific Version of GPL
On 20010830T084026-0400, Jonathan D. Proulx wrote: $ head -3 /usr/share/common-licenses/GPL GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Yes, but that will probably not be true forever. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: Software Licenced Under a Specific Version of GPL
On 20010830T114438-0500, Manoj Srivastava wrote: Flawed assumption. I think you do Debian and the policy group a disservice by claiming that we shall, in the future, have such little regard for copyrights and installed bases. You are being unfair. Most GPL software are licensed with version 2, or at your option, any later version. So, for those, updating the GPL filename to refer to GPLv3 would not be a far-off idea. So, GPL is likely to remain, and refer to a version 2 licence, for a long time, until all packages are changed. I don't think so - look at what we did to LGPL. Violating policy by including the full contents of the common license on the assumption that future developers are going to screw up is not a good idea. It is you who thinks future developers would screw up if they did what Ari fears. IMHO the best thing would be to introduce the GPL-2 symlink now, and not in some far-off point in the future. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#99933: Comments on Unicode
On 20010705T133736-0400, Raul Miller wrote: in HTML the language can only be identified in the mime header. There is no such thing as a MIME header in HTML. Besides, HTML does include the lang attribute for most elements. I wonder what it's for if not for indicating the language. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: Bug#94827: tktable; Build-Depends: debhelper
On 20010502T202937-0400, Joey Hess wrote: Nah, I know how to munge things to produce its brand of ar files. :-) That does not address my point. (Anyway, I can only see a policy should supporting my view, so...) -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: Bug#94827: tktable; Build-Depends: debhelper
On 20010501T114542-0500, Steve Greenland wrote: On 30-Apr-01, 14:33 (CDT), Antti-Juhani Kaijanaho [EMAIL PROTECTED] wrote: You could probably do without the latter two, but IIRC the deb format is internal to dpkg and dpkg-deb is the only supported interface for creating debs. Not true: .deb files are ar(1) archives containing two tar.gz members. See deb(5). I know that and it does not invalidate what I said. Internal does not mean the same as unique. Anyhow, I cannot seem to be able to find the relevant docs that support my position; the only comparable thing is policy saying that one should use dpkg-deb to create debs. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: Bug#94827: tktable; Build-Depends: debhelper
On 20010430T000601-0400, Joey Hess wrote: Now you're tempting me to go make a package that builds without using those nasty helper programs dpkg-deb, dpkg-gencontrol, and dpkg-shlibdeps.. :-P You could probably do without the latter two, but IIRC the deb format is internal to dpkg and dpkg-deb is the only supported interface for creating debs. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: Bug#94827: tktable; Build-Depends: debhelper
On 20010423T091432-0500, Steve Greenland wrote: It's been discussed before. The problem is that most debhelper Build-Depends actually need to be versioned[1], which won't work with build-essential. That's not the real reason. Take the definition of build-essential packages from policy. It specifies that the list will not cantain any packages that are optional in building a package that contains a C or C++ program. It should be clear to everybody that debhelper is not required (there are developers who don't use debhelper - consider in contrast dpkg-dev, which everybody needs) and thus not essential. IMHO, it'd be more in line with the philosophy of build-essentiality to remove the C and C++ compilers from the list than to add debhelper. But both changes will require policy amendments. Antti-Juhani, the build-essential maintainer who is behind in his Debian mail (busy IRL) -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: Must and should: new proposal (was: Re: Must and should again)
On 20010416T104914+0100, Julian Gilbey wrote: Did the ftpadmins ever consider the possibility of running lintian on packages before allowing them into unstable? I believe that all of us ftpmasters run lintian on new packages as part of our set of new package checks. The results are then considered by the human ftpmaster who is doing the check, and most of the time at least I double-check manually the critical problems that lintian tells me about before doing a reject based on that. Packages are not automatically lintianed by katie. IIRC James has said he'll add this as soon as the lintian maintainer says lintian is ready for that. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#72335: PROPOSAL] Optional build-arch and build-indep targets for debian/rules
On 20010411T191823+0100, Julian Gilbey wrote:
I've just found an issue which must be resolved whether this proposal
is accepted or not. At present, the Build-{Depends,Conflicts}-Indep
lists do not apply to the build target. This is incorrect. This
proposal already fixes this issue.
It was intentional: we decided back then that doing that would render
the fields useless.
(It turned out they are useless anyway, but...:-)
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#72335: PROPOSAL] Optional build-arch and build-indep targets for debian/rules
On 20010329T112958+0100, Julian Gilbey wrote: OK, after Wichert's comments, here is a new version of the proposed amendment to policy. Seconded. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% pgpHcMbbIlovJ.pgp Description: PGP signature
Bug#93047: debian-policy: tells GNU Public Licence
On 20010406T060953-1000, Brian Russo wrote: so it is the GGPL then? No, it's GNU GPL. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: where are valid sections defined?
On 20010326T112130-0800, Sean 'Shaleh' Perry wrote: I just received a bug because lintian does not know about the section 'science'. Where is the canonical list of sections? Basically, the set of valid sections is currently defined as whatever sections exist in the master override database in auric and pandora. There may be corner cases. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#90989: proposal] making all control fields multi-line
On 20010325T001056+0100, Cyrille Chepelov wrote: Issues: allowing multiple lines in control fields breaks the use of grep ; however, grep-dctrl exists to alleviate this problem. It is my understanding that this breaks sbuild too. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: [control] continuation lines on relation fields ?
On 20010317T122741+0100, Wichert Akkerman wrote: Previously Cyrille Chepelov wrote: I've got an interpretation problem: can relationship fields be written on multiple lines ? Looking at the dpkg parsing code, yes. Which makes sense, considering we are dealing with RFC822 syntax. I believe that sbuild expects them to be on only one line. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: the math section should really be science
On 20010313T203223+0100, Josip Rodin wrote: Well, none of these are the canonical source, they just read data from it -- the override file, see the /indices/override.* files on every mirror. Actually, the canonical source is Katie's database. Even the override files are nowadays generated from there. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#88249: PROPOSAL] policy process must explicitly include relevant package maintainers
On 20010302T114353+0100, Wichert Akkerman wrote: We actually should consider another change: something can not become policy until there is an existing implementaiton. This rule is also used in the RFC process, and works great there. This particular amendment does not require an implementation. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#88029: allow rules file to be non-makefile
On 20010228T214134+0100, Josip Rodin wrote: I would like to propose that the debian/rules file is allowed to be non-makefile. Any kind of a program that can do the required stuff can be a debian/rules file. We shouldn't prohibit it when someone e.g. writes a short shell script or another interpreted script, as long as it works. Where is your diff to policy? This proposal will require extensive changes to policy wording (including writing a nontrivial specification of debian/rules command-line syntax) if done right, so I will have to object to this proposal until precise changes to the wording are provided. I support the general spirit of this proposal, though. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#72335: ACCEPTED 31/10/2000] Optional build-arch and build-indep targets for debian/rules
On 20010301T103402+, Julian Gilbey wrote: (and notwithstanding that we're going to require both or neither), it should say that debian/rules -q with one of the not-provided targets ... Sounds like a good idea. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#88111: policy should not dictate implementation details
On 20010301T155542+, Julian Gilbey wrote: In particular, the following should be minimally required: debian/rules required-target exit status: 0 if success, non-zero otherwise debian/rules -q target exit status: 2 if target does not exist, !=2 otherwise Also the debian/rules VAR=VALUE ... syntax is used by dpkg-buildpackage. Once that is done, I think I'll be happy with the proposal. There is already another proposal about this. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#88111: policy should not dictate implementation details
On 20010301T152221+0100, Wichert Akkerman wrote: I'll make this a proposal then: Section 5.2 of policy currently dictates that debian/rules has to be a makefile. While this is good practice, the only thing that is essential is that it is an executable that will respond to the build, clean, binary, binary-arch and binary-indep targets. That is false. Currently policy defines the interface of a debian/rules and even some of its behaviour by saying that it is a Makefile. If we decide to remove that requirement, we will need to specify its interface and behaviour another way. As such I propose that the statement that debian/rules has be to a makefile be removed. I object to this proposal, since it leaves debian/rules interface and behaviour unspecified in many instances. And there is already another proposal about this. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#88111: policy should not dictate implementation details
On 20010301T172047+0100, Wichert Akkerman wrote: Previously Julian Gilbey wrote: debian/rules -q target exit status: 2 if target does not exist, !=2 otherwise This has *never* been required, was never documented anywhere, and is not needed at all. It is part of an accepted policy amendment. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#88111: policy should not dictate implementation details
On 20010301T174940+0100, Wichert Akkerman wrote: Right, and my argument is that that is wrong. If debian/rules is a makefile or not is an implementation detail and should not be specified in policy. Policy should specify the interface to it. I have no problems with this, actually I agree. I just want to shoot down half-baked attempts to implement it :-) Indeed, see my patch in another mail. OK. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#87828: PROPOSAL] Deprecate confusing Build-Depends arch syntax
On 20010226T234331+, Julian Gilbey wrote: This allows things like [!i386 m68k], which is equivalent to [!i386] but is just plain confusing. So I'd like to deprecate this and allow only [arch1 arch2 arch3 ...] or [!arch1 !arch2 !arch3 ...]. The wording will become: Seconded. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% pgpahHFDgFvg4.pgp Description: PGP signature
Bug#87510: PROPOSAL] Make build dependencies a MUST
On 20010225T014140+, Julian Gilbey wrote: Policy should now require packages to specify build time dependencies (i.e., packages which require ... MUST specify...) Build time dependencies have been in policy for 18 months already. Seconded. BTW, this was how I intended it when I wrote those bits of policy. The transition to formalized MUST/SHOULD/MAY seems to have missed this bit. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% pgp6gpFWJ9d2s.pgp Description: PGP signature
Bug#87510: PROPOSAL] Make build dependencies a MUST
On 20010225T141840+0200, Antti-Juhani Kaijanaho wrote: On 20010225T014140+, Julian Gilbey wrote: Policy should now require packages to specify build time dependencies (i.e., packages which require ... MUST specify...) Build time dependencies have been in policy for 18 months already. Seconded. Thinking about this a little more, I'm revoking this second. I want to see the diff to policy. It's possible to wreck this whole thijng with careless wording. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% pgphT5TZMngsA.pgp Description: PGP signature
Bug#87510: PROPOSAL] Make build dependencies a MUST
On 20010225T131051+, Julian Gilbey wrote: Of course, with the question of empty dependency lists, there's a problem Indeed, and I'd like that to be explicitly addressed somewhere. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: [PROPOSAL] cron.* scripts should be quiet
On 20010213T084841-0800, Joey Hess wrote: I dislike it. It's possible some package will exist that is _designed_ to fire off daily status reports by cron. We shouldn't prohibit such things without reason. An example is vrms. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% http://groups.google.com/ Thank you to all who cared.
Re: [PROPOSAL] Allowing crypto in the main archive
On 20010111T010726+0100, Rene Mayrhofer wrote: I am now about 2 - 3 days away from my first upload of freeswan. Should it go into net (instead of non-US) now ? :-) No. A proposal does not automatically mean a policy change. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Keep the Deja Archive Alive! http://www2.PetitionOnline.com/dejanews/petition.html
Bug#72335: PROPOSED] Optional build-arch and build-indep targets for debian/rules
On 20001031T195631+, Julian Gilbey wrote: So even though this languished for a month, I would like to reopen this proposal and second it. Okay. I hereby withdraw my earlier withdrawal of this proposal. It's open again. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#72335: PROPOSED] Optional build-arch and build-indep targets for debian/rules
retitle 72335 [WITHDRAWN] Optional build-arch and build-indep targets for debian/rules thanks Due to lack of interest, I am withdrawing this proposal.
Bug#72335: PROPOSED] Optional build-arch and build-indep targets for debian/rules
On 2925T152912+0200, Roman Hodek wrote: A patch to dpkg-buildpackage is sufficient, as the daemons just call dpkg-buildpackage -B. Ok. Does it make sense to allow one 'build-*' target without the other? If a package can utilize the separation, it needs both anyway. In extreme cases, one of the targets still can be empty. But requiring both makes it easier to test for them. You're right. I'm too tired to fix the diff now, and I'm going away for the weekend. Anybody willing to fix the diff for me? :-) But besides this, I support this proposal. Is that a second? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#72335: [PROPOSED] Optional build-arch and build-indep targets for debian/rules
Package: debian-policy Version: 3.2.1.0 Severity: wishlist There is a problem with the current build-time dependency system. The build-time dependency system separates between dependencies needed to build architecture dependent and architecture independent packages via the Build-Depends and Build-Depends-Indep fields in debian/control. However, since all compilation of the package must happen in the build target of debian/rules (Packaging Manual section 3.2.1), and since Build-Depends applies to the build target (Packaging Manual section 8.7), it means that very rarely can Build-Depends-Indep used, and also that build daemons building only architecture-dependent parts of the package need often install also everything needed to build the architecture-independent parts. This is not good. Therefore, I propose two new optional targets in debian/rules. They would be named build-arch and build-indep, mirroring the already existing binary-arch and binary-indep targets. When they exist, the build target would have to depend on them; if they don't exist, the build target must do what they would do. Additionally, the semantics of the build-time dependency fields would be changed so that Build-Depends-Indep would apply to the build, build-indep, binary and binary-indep targets, and Build-Depends would apply to the build, build-arch, binary and binary-arch targets. Thus when a builder wants to build only arch-dependant parts of the package, she can invoke first the build-arch target (as non-root, if wanted) and then the binary-arch target (as root). Then only Build-Depends packages would need to be installed, fixing the problem. The reason that the targets be optional is to not make this proposal cause a major version number increment in policy if the proposal is accepted. Since the targets are optional, only those packages suffering from the problem outlined above will want to change, and no packages need to change. This proposal requires no code changes anywhere. However, to make use of the proposal's improvements to the build system, dpkg-buildpackage and the build daemons will need to be changed to detect and use the new targets. I will provide a patch for dpkg-buildpackage, if necessary. This proposal affects only the packaging manual. A diff of the SGML source is attached. I'm mainly looking for comments and criticism, but seconds are also appreciated. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% --- packaging.sgml.orig Sun Sep 24 16:42:17 2000 +++ packaging.sgml Sun Sep 24 17:16:29 2000 @@ -948,10 +948,11 @@ p The targets which are required to be present are: taglist - tagttbuild/tt/tag + tagttbuild/tt, ttbuild-arch/tt (optional), +ttbuild-indep/tt (optional)/tag item p - This should perform all non-interactive + The ttbuild/tt target should perform all non-interactive configuration and compilation of the package. If a package has an interactive pre-build configuration routine, the Debianised source package should be @@ -959,6 +960,37 @@ built without rerunning the configuration. /p +p + A package may provide one or both of the targets + ttbuild-arch/tt and ttbuild-indep/tt. The + ttbuild-arch/tt target, if provided, should + perform all non-interactive configuration and + compilation required for producing all + architecture-dependant binary packages (those + packages for which the body of the + ttArchitecture/tt field in + ttdebian/control/tt is not ttall/tt). + Similarly, the ttbuild-indep/tt target, if + provided, should perform all non-interactive + configuration and compilation required for producing + all architecture-independent binary packages (those + packages for which the body of the + ttArchitecture/tt field in + ttdebian/control/tt is ttall/tt). The + ttbuild/tt target should depend on those of the + targets ttbuild-arch/tt and ttbuild-indep/tt + that are provided in the rules file. +/p + +p + If one or both of the targets ttbuild-arch/tt + and ttbuild-indep/tt are not provided, then + invoking ttdebian/rules/tt with one of the + not-provided targets as arguments should produce a + exit status code of 2. Usually this is provided + automatically by make if the target is missing. +/p + p
Re: Bug#70269: automatic build fails for potato
On 2902T005640-0500, Manoj Srivastava wrote: misleading, note in policy, would it not be better to instead improve the visibility if the build depnds package and arrange to have the updated contents present on the web page? The web page part is already arranged, see Developer's Corner. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: Bug#70269: automatic build fails for potato
On 2902T124921+0200, Arthur Korn wrote: BTW: why is it even a seperate package? IMO the build-essential list should be included with ether the debian-policy package or the packaging-manual. This way every debian developer has this lists in a sensible place already installed. There were several reasons: 1) the current system allows maintaining the list separately from the policy documents (the list does not need the kind of control that the policy documents do) 2) the package brings in the build-essential packages using the depends relation 3) the separate package allows bug reports against the package to be categorized separately from the policy management process that uses the BTS BTW, task-debian-devel depends on build-essential, so many Debian developers have the package installed anyway. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: Bug#70269: automatic build fails for potato
On 2901T104626-0500, Steve Greenland wrote: find. The policy manual says look in build-essential. The control file for Build-essential says look in policy manual The policy manual says look for the *informational* list in build-essential. build-essential says look for the *definition* in the policy manual. I don't see the problem. and includes two different list files, one of which is completely pointless, the other of which has the needed info buried in the middle of a bunch of definitions and syntax. I wonder why I haven't seen a bug report from you about this. Just put the list on the website, It is in the website, starting yesterday. Why are people determined to make information so hard to find? Why are people determined to make pointless rants instead of filing useful bugs? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#70634: Typo in policy manual
Package: debian-policy Version: 3.2.1.0 On 2830T184956-0400, Matt Zimmerman wrote: On Wed, Aug 30, 2000 at 08:51:47PM +0300, Antti-Juhani Kaijanaho wrote: The definition is the following: It is not be necessary to explicitly specify build-time relationships on a minimal set of packages that are always needed to compile, link and put in a Debian package a standard Hello World! program written in C or C++. The required packages are called _build-essential_, and an informational list can be found in `/usr/share/doc/build-essential/list' (which is contained in the `build-essential' package). (Debian Policy v. 3.2.1.0, section 2.4.2.) I can't find a bug open regarding the obvious grammatical error at the beginning of this paragraph (It is not be). Is someone aware of it nonetheless? I imagine it should read It is not necessary -- - mdz Why didn't you file the bug then? (I believe it originally said it will not be and then somebody edited it.)
Re: Bug#70269: automatic build fails for potato
On 2830T234249+0100, Julian Gilbey wrote: On Wed, Aug 30, 2000 at 01:06:30PM -0500, Steve Greenland wrote: Which is just a stupid pain in the ass. I had to track through three different references and finally install the build-depends package to find out what I could leave out of by Build-Depends stanza. It would *much* easier for developers, if less ideologically pure, to just list the damn packages on the Developers Corner part of the website. Could we add this as a footnote to the relevant section in policy or the packaging manual (can't remember which offhand)? Um, the current note in policy manual is not sufficient? (It explicitly mentions the package build-essential.) -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Hypertekstivisionääri Ted Nelson luennoi Jyväskylässä 29.-31.8. Lisätietoja saa minulta.
Re: Bug#70269: automatic build fails for potato
On 2829T010700+0200, Wichert Akkerman wrote: Previously Josip Rodin wrote: On Mon, Aug 28, 2000 at 06:23:52PM +0200, Marcus Brinkmann wrote: The packaging manually actually says it is a makefile: Yes, and that makes it policy. No it doesn't. Interesting. I seem to recall that Packaging manual was going to be part of policy when the current update mechanism was being drafted. I've since always assumed that Packaging manual is policy, and worded my policy amendment(s?) accordingly. It does contain some cruft that needs to be removed from policy, yes, though. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Hypertekstivisionääri Ted Nelson luennoi Jyväskylässä 29.-31.8. Lisätietoja saa minulta.
Re: Bug#70269: automatic build fails for potato
On 2828T172935+0200, Paul Slootman wrote: An informational list can be found in package `build-essential'. (NOTE: Don't file bugs about debhelper against this package. They will be summarily closed. If you feel that the criteria for selecting build-essential packages are wrong, bug debian-policy.) [ I don't read debian-policy ] Hmm, the dependency on make is flawed, as it is perfectly possible to write debian/rules that is a perl script, for example. If you find a flaw in my application of the criteria, bug reports against build-essential are welcome :-) BTW, note that Packaging Manual section 3.2.1 requires that debian/rules is a makefile. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Hypertekstivisionääri Ted Nelson luennoi Jyväskylässä 29.-31.8. Lisätietoja saa minulta.
Re: Q about Build-Depends vs Build-Depends-Indep
On Wed, Jun 21, 2000 at 05:42:16PM +0100, Julian Gilbey wrote: So how about modifying the wording to say: Build-Depends, Build-Conflicts The Build-Depends and Build-Conflicts fields describe binary dependencies and conflicts which must be satisfied when making the build, binary, binary-arch and binary-indep targets. Build-Depends-Indep, Build-Conflicts-Indep The Build-Depends-Indep and Build-Conflicts-Indep fields describe binary dependencies and conflicts which must be satisfied when making the binary and binary-indep targets. How would you modify the preceding paragraph? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: unusable examples in apckages ...
On Tue, May 30, 2000 at 11:58:58AM +0200, Sven LUTHER wrote: -- if a package contains examples that need to be compiled, they must be in such a state in the package that the user can just copy the directory to its home directory (or /tmp/ or wherever) and build the examples with no more hassle than typing ./configure and/or make. -- You are saying that every (source) example/ directory requires a Makefile? Please don't CC me. I'm on this mailing list. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: unusable examples in apckages ...
On Tue, May 30, 2000 at 02:01:55PM +0200, Sven LUTHER wrote: not every user is aware of all that needs done to use a -dev package, that is what the examples are for, and they should be useable by the user. Not all such examples are for -dev packages. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: MUST and SHOULD in policy
On Sat, May 06, 2000 at 01:36:51AM +1000, Anthony Towns wrote: packages should generally adhere to most of the guidelines denoted by *should* (or *recommended). This is a circular definition and buys nothing. I recommend: ... packages that fail the guidelines denoted by SHOULD or RECOMMENDED are not suitable for the Debian distribution except in exceptional situations - or something like that (probably should weaken the condition a little). -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% I'm moving IRL on May 2, 2000. New contact information on the home page
Bug#62947: PROPOSAL] s/debian-devel/debian-legal/
On Mon, Apr 24, 2000 at 01:40:40PM +0200, Santiago Vila wrote: Since the debian-legal mailing list exists and it was specifically created to discuss copyright and licensing issues, the above reference should be changed to refer to [EMAIL PROTECTED]'. I'm looking for seconds for this proposal. Seconded. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% I'm moving IRL on May 2, 2000. New contact information on the home page
Re: Bug#53054: pygresql: change version number to reflect correct upstream version
Yes, it's just in the packaging manual... yes, that is not policy... *yet* Actually, the DPaM is policy, altough it contains some material that ought not to be. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Bug#50832: AMENDMENT] Clarify meaning of Essential: yes
On Thu, Dec 09, 1999 at 12:19:34AM +1000, Anthony Towns wrote: ldso and libc6 are already Essential, so the dynamic linker, and libc6 are guaranteed to be available. If libc6 were Essential, it'd violate policy. And, indeed, it is not: [EMAIL PROTECTED]:34:15]:pip$ grep-available -sEssential -PX libc6 Essential: [EMAIL PROTECTED]:34:25]:pip$ -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Bug#51879: PROPOSAL: package may be maintained by a group
On Fri, Dec 03, 1999 at 03:56:35PM -0800, Joey Hess wrote: + Every package must have exactly one maintainer at a time. The + maintainer may be a mailing list. A mailing list is a computer file in a mail server, or (alternatively) an email address that delivers mail to multiple human recipients. It cannot fix bugs, it cannot maintain software, it cannot debate technical points. I suggest you replace a mailing list with a group of people reachable from a common email address, such as a mailing list. Yes, this is nitpicking. Policy is a spec, and it needs to be treated as such. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Bug#51879: PROPOSAL: package may be maintained by a group
On Fri, Dec 03, 1999 at 06:54:27PM -0800, Joey Hess wrote: Sure, I amend my proposal to use Antti-Juhani's wording. In that case I second the proposal. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Bug#51412: conflict in documents
On Sun, Nov 28, 1999 at 12:01:44AM -0700, Bdale Garbee wrote: There needs to be a canonical list of the packages that are part of the build-essential set *somewhere*. Why? The point of the current way is to reduce the risk of having an outdated authoritative list of build-essential packages. *And* it makes it possible for us to update the list without going through the policy amendment procedure every time something changes in the build setup. It is my intention to keep the list as accurate as I can, but I don't like to mention specific packages in policy. That's another reason why build-essential is not authoritative. This all was discussed when the build-time dependency spec was being hammered out on -policy. The fact that the policy is vague It is not vague. The definition is (or at least attempts to be) unambiguous. It takes a little effort to find out what the set actually is, but presumably you cannot arrive in two different sets based on that definition. The build-essential package is there to provide you a precalcualated set. However, if I made a mistake in determining the set, the mistake is not automatically part of policy. This is yet another point for the current arrangement. and the list in your package carries a wimp-out disclaimer in combination fails to meet this need. I rephrased the disclaimer a little for build-essential 2, which is in Incoming. Is it satisfactory now? If not, can you suggest a better wording? It seems that what you are really saying is that this is another bug in the policy. No, I am saying that the arrangement is like this by design, not by accident. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Bug#50832: AMENDMENT] Clarify meaning of Essential: yes
On Tue, Nov 23, 1999 at 02:54:56PM +, Julian Gilbey wrote: On Tue, Nov 23, 1999 at 11:02:24PM +1000, Anthony Towns wrote: close 50832 reopen 50832 Huh?! Amendment [...] DD/MM/YYY] Actually it might be better to close the proposal and reopen so the bug date reflects when the clock starts ticking on the bug. (/usr/doc/debian-policy/proposal.text.gz) -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Bug#49901: Correction to the build-dependency spec, Packaging manual section 8.1
Package: debian-policy Version: 3.1.0.0 - Forwarded message from Antti-Juhani Kaijanaho [EMAIL PROTECTED] - Date: Tue, 9 Nov 1999 18:13:45 +0200 From: Antti-Juhani Kaijanaho [EMAIL PROTECTED] To: debian-policy@lists.debian.org Subject: Correction to the build-dependency spec, Packaging manual section 8.1 I feel ashamed. My initial draft for the build-dependency specification - which was carefully put together after a period of experimentation and checking of prior art - did not include the architecture specifications ([!i386]). It was added very late in the process after Marcus Brinkmann and Joel Klecker had lobbyed hard for it. When I wrote my final draft, I added them and wrote the relevant language with too little thought, as it turns out. The result is a humiliating error in the spec, which should be corrected ASAP. Here's the relevant part of the Packaging Manual, section 8.1, last non-example paragraph: An exclamation mark may be prepended to each name. If the current Debian host architecture is not in this list, or it is in the list with a prepended exclamation mark, the package name and the associated version specification are ignored completely for the purposes of defining the relationships. The idea was that [!i386] would be ignored ONLY in i386 and used by other architectures. As it turns out, the wording of the spec means something quite different: Suppose we're building on alpha, and we need to decide whether kernel-headers-2.2.12 [!hurd-i386 !m68k] is a relevant dependency. We check that + alpha is not in the list [!hurd-i386 !m68k], and + alpha is not in the list [!hurd-i386 !m68k] with a prepended exclamation mark and therefore conclude that the dependency must be ignored. In fact, this reasoning is valid for all values of alpha not equal to hurd-i386 or m68k, and therefore [!X !Y !Z ...] means always ignore me. Ouch! I think it is quite clear that this is not what was intended, and therefore I ask the policy editors to consider this problem a typo on my part, and replace the quoted paragraph with the following, which should reflect the intended semantics: An exclamation mark may be prepended to each name. If the current Debian host architecture is not in this list and there are no exclamation marks in the list, or it is in the list with a prepended exclamation mark, the package name and the associated version specification are ignored completely for the purposes of defining the relationships. The only change is the addition of the phrase and there are no exclamation marks in the list. Theorem: This paragraph does indeed reflect the intended semantics. Proof: It is easy to see that the exclamation mark defines exclusion from the set and the absence of the exclamation mark defines inclusion in the set. The base set for the exclusion is the set of all architectures, since all architecture names which are not mentioned with an exclamation mark are included; that is, [!m68k !sparc] means the same as [alpha arm hurd-i386 i386 powerpc]. If there are architecture names without an exclamation mark when the list contains names with an exclamation mark, the list is equivalent to one without the names without the exclamation mark; that is, [i386 !m68k !sparc] means the same as [!m68k !sparc]. _ |_| [How did I notice this? I was putting together the build-essential package and decided to use the same syntax in a certain file which is used for generating the /usr/share/doc file and the dependencies. I tried to state the semantics in a different, more formal way, in which the problem was obvious.] -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Bug#49901: Marking bug forwardeed
forwarded 49901 debian-policy@lists.debian.org thanks This bug is not a proposal or amendment; it is a typo bug, and is now marked forwarded so that the policy editors may do with it whatever they choose. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Uploaded build-essential 1 (source i386) to master
[ Watch your recipient list on replies and followups. ] I've just uploaded the first version of the build-essential package to master. The .changes file is below. The package is architecture-specific because its Depends line varies between architectures. (BTW, Hurd people should check if the list is valid for the Hurd. The same for other architectures.) -BEGIN PGP SIGNED MESSAGE- Format: 1.6 Date: Tue, 9 Nov 1999 14:18:34 +0200 Source: build-essential Binary: build-essential Architecture: source i386 Version: 1 Distribution: unstable Urgency: low Maintainer: Antti-Juhani Kaijanaho [EMAIL PROTECTED] Description: build-essential - Informational list of build-essential packages Changes: build-essential (1) unstable; urgency=low . * New package. Files: 4570844176732f4c1e2867ee84ea8365 612 devel extra build-essential_1.dsc 1ccab4e71ebdbdc5302685e7e61d2bd9 7155 devel extra build-essential_1.tar.gz d83d601fa547e39d50bb0445fb53bbc9 4894 devel extra build-essential_1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBOCl6MJcxRnRt1gOFAQE2MAQAhzi08iDZovNgt3uOgzCOsFC4JsoYD/A1 eovgpIyWBVabxFjwIY0WIHGu5FpF/syeGaPcBgLebywId3qDX1NDlmzToadFBVeR l7HyjfaQ1jZKxlDD5Xf/gF3sYXlsi7ImpZFICy0s+4koPK2Q/k8U1LqjC/p5sADX oCDGsOBRaCo= =S4R3 -END PGP SIGNATURE- -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: compressing copyright
On Thu, Nov 04, 1999 at 11:04:58AM -0800, Seth R Arnold wrote: This is where I disagree. I have been wondering myself over the last few days, how many of the non-free and contrib and so forth have I installed on my system? How many packages are *not* free? I think if I were to take the time, I could write a quick little script to grep through all /usr/share/doc/package/copyright.txt to find out which ones are free and which ones aren't. [EMAIL PROTECTED]:21:59]:~$ grep-available -PX vrms Package: vrms Priority: optional Section: admin Installed-Size: 20 Maintainer: Bill Geddes [EMAIL PROTECTED] Architecture: all Version: 1.4 Filename: dists/unstable/main/binary-i386/admin/vrms_1.4.deb Size: 4846 MD5sum: d3eaba04b05796a2d92cb41b97674749 Description: Virtual Richard M. Stallman The vrms program will analyze the set of currently-installed packages on a Debian GNU/Linux system, and report all of the packages from the non-free tree which are currently installed. . Future versions of vrms will include an option to also display text from the public writings of RMS and others that explain why use of each of the installed non-free packages might cause moral issues for some in the Free Software community. This functionality is not yet included. [EMAIL PROTECTED]:22:06]:~$ -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
ITP: build-essential
As previously discussed on -policy, I am announcing my intent to create a new metapackage called `build-essential'. Its primary function is to serve as the informal list of build-essential package referred to by the forthcoming policy edition. It fulfills this mission in two ways: * It will Depend: on all non-essential packages which are build-essential * It will install a file /usr/share/doc/build-essential/list, which contains the informational list of build-essential packages. Publishing this list as a metapackage gives us several advantages: * it suffices to install this package to get an environment required for building Debian packages + consequently, to build a given package A, you just need to install this package and the packages A lists as its build-time dependencies. + consequently, all implementations of the build-time dependency spec will automatically use the same list of build-essential packages * To report an error in this list, just reportbug build-essential. * Since this is an ordinary package, it takes nothing special to maintain two different versions of it, one for stable and one for unstable (and occasionally yet another for frozen). Why not call this task-build-essential, as I originally proposed? Because this is not a task package and should not presented for installation at system install time with the other metapackages. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 04:51:23PM +0200, Wichert Akkerman wrote: Previously Antti-Juhani Kaijanaho wrote: How do you define complete implementation? A dpkg-source that: a) supports build-dependencies b) supports multiple patches c) can setup a buildroot and start building everything that is needed to build a package Right now c) doesn't seem to work correctly on Linux systems, otherwise it seems to work fine. I had a look at Klee's sources. They're poorly documented and they do too much to be relevant to this policy amendment. But the ideas are interesting, so I'll see if I can figure the sources out and do something about them ;-) Is it orphaned by Klee, ie. are we looking for a new upstream developer or...? IMHO you should not delay adding the patch to dpkg-dev. Klee's source format is not relevant to this amendment. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Draft policy 3.1.0.0 now available
On Tue, Oct 26, 1999 at 10:56:45PM -0700, Joey Hess wrote: in C or C++. The required packages are called _build-essential_, and an informational list will be published separately from this document. I don't see that list. I've been thinking about publishing this list as a task metapackage called task-build-essential or something. It would have several advantages: * anybody who wishes to build a package needs only install this package and whatever the package specifies * all build-time dependency implementations get to use the *same* list very easily * we get the handling of several versions of the list (one for stable, one for unstable) for free from the usual release process * it will be easy to report bugs in the list: just bug the metapackage What do people think? I am volunteering to maintain this package unless somebody else wants it badly. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
Remember the definition of build-essential: + p +It will not be necessary to explicitly specify build-time +relationships on a minimal set of packages that are always +needed to compile, link and put in a Debian package a +standard Hello World! program written in C or C++. The +required packages are called em/build-essential/, and an +informational list will be published separately from this +document. + /p + On Wed, Oct 27, 1999 at 03:50:06AM -0700, Seth R Arnold wrote: [ What's build-essential?] Joel Klecker: libc-dev Yes: gcc Definitely. g++ yes. libstdc++-dev yes. patch Only if something else requires it. (dpkg-source?) make Yes. dpkg-dev Yes. binutils Yes. bison No. autoconf ? No. bin86 ? Do you need this to compile a Hello World? ldso ? Do you need this to compile a Hello World? supporting stuff tar ? Only as a dependency. cpio ? Only as a dependency. gzip ? Only as a dependency. bzip2 ? Only as a dependency. find ? What needs this? perl ? What needs this? less likely, but still possible... curses ? No. groff/man ? No. wish ? No. python ? No. jdk ? No. Remember, this list is supposed to be MINIMAL. BTW, what do you people think of the metapackage idea (see the new Policy draft thread)? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 07:22:00AM -0400, Ben Collins wrote: Should dpkg-dev possibly depend on anything we consider to be assumed for build dependencies? I'd create a separate metapackage for that, as I already proposed elsewhere. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 08:00:47AM -0400, Ben Collins wrote: I'd create a separate metapackage for that, as I already proposed elsewhere. But then dpkg-dev should still depend on that (which would be good and let it get rid of all the other deps it needs/has). On the contrary: dpkg-dev should depend on what it needs, and the metapackage should depend on dpkg-dev. This way the only thing that needs to be preserved is the name of the metapackage; at some later date dpkg-dev need not be build-essential (think about Klee's dpkg-source, for example). The idea is that you only need to apt-get install the metapackage and whatever the Build-* fields specify to build a package. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 01:56:04PM +0200, Roman Hodek wrote: Such a metapackage surely will be useful. However, I think the build-essential list still should be written down somewhere :-) Well, if the metapackage is in the available file, the following shell code will create such written list (untested): grep-available -PX task-build-essential -sDepends -n | tr ',' ' ' build-essential.txt This is trivially automatisable. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Wed, Oct 27, 1999 at 09:06:00AM -0400, Raul Miller wrote: Last time I checked, apt-get update did not update the available file. That's true but irrelevant. I was providing an existence proof, not a fully thought-out implementation. I will probably just generate the information at metapackage build time to both the Depends line and the /usr/share/doc file (which can, additionally, be installed in the web pages, if people prefer that). -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Build dependencies: some thoughts
On Wed, Oct 27, 1999 at 03:17:52PM +0100, Julian Gilbey wrote: It's not easy. In fact it's *really* not easy. It is easy. I've specified build-time dependencies on some of my packages for months now. You just happened to try a nasty case as your first. Standard packages: dpkg-dev, lynx, make Now these should need listing, as they are not marked essential. dpkg-dev and make are obviously build-essential. Firstly, that if we are now demanding build-time dependencies, we are asking maintainers to do a *lot* of work. (This took me about 2 hours, maybe a little bit more.) As I said, this package is complicated. For my packages, it has been almost trivial to list the few build-time dependencies. Thirdly, of the packages listed, dpkg-dev and make are needed by every package build, so should not be needed to be listed. I wonder whether we can have a tag Build-Essential: yes for a small number of packages which are assumed to be present on any builder, and that do not need to be listed? It seems you have not read the amendment. There was a mechanism for this even in the first draft. And I would have appreciated these comments at the proposal stage, when we were still hammering out the thing. I even called for people with complicated packages to give their input when I made the proposal. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 12:15:52AM -0700, Joel Klecker wrote: wtf? when did the proposal change to Source-Depends:? there's no evidence of that in the logs. *My* proposal has never changed that way (#41232). The fields are: Build-Depends: Build-Depends-Indep: Build-Conflicts: Build-Conflicts-Indep: -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 01:54:58PM +0200, Wichert Akkerman wrote: Yes. And I won't think I want to change dpkg and friends to accept the fields until someone comes up with a complete implementation. How do you define complete implementation? The build daemon folks have had a working implementation for ages, all that needs to be done is to get that system to parse these fields. I'm annoyed though, that everyone is completely ignoring a *working* implementation of source-dependencies simply because nobody is willing to clean it up a little and package it. How can that happen??? What are you talking about? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 04:30:50AM -0700, Joel Klecker wrote:
I do have a problem with the text for policy; it does not explain the
difference between Build-Indep-{Depends,Conflicts} and
Build-{Depends,Conflicts}.
The difference is clearly defined by the amendment. The
Build-{Depends,Conflicts}-Indep fields will be consulted only when the
architecture-independent packages are being built. In other words, they
will *not* be consulted when doing a architecture-dependent packages only
build (for example, like the build daemons do).
Someone who simply reads the new policy will have no clue (besides
perhaps guessing that the -Indep form has some relation to
binary-indep) what exactly the difference is and in what situations
each is used.
Here's a rule of thumb: if your source package builds only
architecture-dependent packages, use only Build-{Depends,Conflicts}.
If it builds only architecture-independent packages, you get too choose.
If it builds both, use Build-{Depends,Conflicts} to specify build-time
dependencies needed to build the architecture-dependent packages and
put in Build-{Depends-Conflicts}-Indep whatever additional packages are
needed to build the architecture-independent packages.
I really wish you had spoken up back then when we could have made the
wording more clear on this.
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
(John Cage)
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 07:13:27PM +0200, Wichert Akkerman wrote: The name dpkg-source here is a bit if a misnomer; it is in fact the name of a package that includes new versions of dpkg-source, dpkg-buildpackage, dpkg-genchangers, etc. I have the tarball available for anyone who wants to play with it. I would be interested in taking a look at it. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Bug#47438: copyright statement needs updating?
On Sun, Oct 24, 1999 at 08:23:40AM -0400, Raul Miller wrote: Only the owner of copyright in a work has the right to prepare, or to authorize someone else to create a new version of that work. Accordingly, you cannot claim copyright to another's work, no matter how much you change it, unless you have the owner's consent. See Circular 14. This is true. Conversely, once you change a work with the consent of the original author, the result is no longer the original work, it is a derived work and the copyright on that derived work is held jointly by the original author and the author of the changes. The point is, Ian does not hold the copyright to the whole of Debian Policy Manual. He holds copyright to the original which he wrote and to those parts of the current version that he has authored. The copyright on the current version is jointly held by all people who have made significant changes to the manual. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: persistence of /usr/doc/$pkg (Was: debhelper: /usr/doc problems again)
On Wed, Oct 06, 1999 at 03:01:05PM -0500, Manoj Srivastava wrote: I have a shell script that does the above algorithm, if people are interested. Yes. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Bug#45406: PROPOSAL] Config files must have manpages
On Sat, Sep 18, 1999 at 06:26:53PM -0700, Joseph Carter wrote: On Sat, Sep 18, 1999 at 02:32:09PM -0300, Nicolás Lichtmaier wrote: Should be add `intended for direct user modification'? Are there configfiles that are `internal' and should be allowed to remain undocumented? Yes there are some such config files. I believe tetex has one, for example. Which is...? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Bug#45406: PROPOSAL] Config files must have manpages
On Sat, Sep 18, 1999 at 04:10:42AM -0300, Nicolás Lichtmaier wrote: Most configuration files have manpages, but not all. It would be useful if every config file (intended to be edited) would be forced to be documented in a manpage. What is the actual change of wording you propose for policy? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Bug#32263: Split /cgi-bin/ into system and local parts
On Thu, Sep 09, 1999 at 08:17:46AM -0400, Brian White wrote: on the bug report or in the debian-policy mailing list archives. Would somebody fill me in as to why it was rejected? Thank you! Because nobody cared about this proposal enough to second it, I'd wager. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: [PROPOSAL] changing policy on compiling with -g .. a better way
On Tue, Aug 31, 1999 at 11:51:46AM +0200, Roman Hodek wrote: And since the build targets of contain a lot of commands, a second build-debug target often will mean to double most of these commands. No. Just set up the regular build target so that it honours the setting of BUILD_DEBUG and add this to debian/rules: build-debug: BUILD_DEBUG=y build-debug: build You can use other make variables of course. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: [PROPOSAL] changing policy on compiling with -g .. a better way
On Tue, Aug 31, 1999 at 07:27:35AM -0400, Ben Collins wrote: I think sticking with an env will make it much easier for some one to just Of course. I just wanted to point out that it is possible to avoid code duplication even in a Makefile :-) -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: [PROPOSAL] changing policy on compiling with -g .. a better way
On Tue, Aug 31, 1999 at 02:36:37PM +0200, Roman Hodek wrote: build-debug: BUILD_DEBUG=y Is that a GNU make feature that you can set vars at the place where a dependency is expected? At least it works with GNU make, and it's documented in the node Target-specific Variable Values of the Make info file. I don't know how widely this is implemented by other makes. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Bug#41232: debian-policy: [ACCEPTED] Build-time dependencies on binary packages
retitle 41232 [ACCEPTED] Build-time dependencies on binary packages forwarded 41232 debian-policy@lists.debian.org thanks I think it is safe to say this amendment is accepted. If you don't agree, speak up *now*. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Bug#41232: AMENDMENT 1999-07-23 FINAL DRAFT] Build-time dependencies on binary packages
On Sat, Aug 07, 1999 at 02:18:41AM +0300, Antti-Juhani Kaijanaho wrote: Thus the discussion should end on Friday, the 13th of this month. This deadline is almost at hand. I've produced a final draft of the amendment for your review. Consider it frozen: i will not make any substantial changes to it anymore - only simple thinkos and typos will be corrected. I hope we can get a consensus to back this amendment; otherwise, we'll have to reject it. (There will of course be the option of starting a new proposal with new seconds and a new discussion period.) To concentrate the remaining discussion on the matters at hand, I'll summarise the points of disagreement and add my comments. I'll summarise my final positions on those issues here, as they are resolved in the draft. * Are Build-Conflicts really necessary? Yes. * Do we need to conditionalize the build dependencies based on architectures? Yes. Conditionalisation is supported based on host architecture. If it is necessary, a separate amendment can establish a way to conditionalise based on build architecture. * If so, what syntax should we use? I've chosen the package (= 42) [i386 !hurd-i386] syntax. It's moderately non-intrusive, and the separate parenthetical forms emphasize the difference between the two add-ons: the version specification narrows the relationship, the architecture specification conditionalises it. Commas are not allowed as separators, as that would needlessly compilcate parsers. The set definition syntax is simple but AFAICS expressible enough. If fancier syntaxes (such as [hurd-*]) are needed, they can be introduced in a separate amendment. * Should we use four fields or six fields? Four. * When are versioned dependencies necessary? Every time not using them would result in bad or inconsistently configured packages. This amendment contains a couple of other modifications that have either been discussed and agreed on earlier or that merely enhance the language. This amendment will not introduce build-recommendations or build-suggestions. They can be introduced in a separate amendment. Here are the diffs against policy and packaging manual version 3.0.1.0: --- policy.sgml.origThu Aug 12 03:36:37 1999 +++ policy.sgml Thu Aug 12 03:58:13 1999 @@ -932,6 +932,51 @@ release it./p/sect1 +sect1 + headingPackage relationships/heading + + p +Source packages must specify which binary packages they +require to be installed or not to be installed in order to +build correctly. For example, if building a package +requires a certain compiler, then the compiler must be +specified as a build-time dependency. + /p + + p +It will not be necessary to explicitly specify build-time +relationships on a minimal set of packages that are always +needed to compile, link and put in a Debian package a +standard Hello World! program written in C or C++. The +required packages are called em/build-essential/, and an +informational list will be published separately from this +document. + /p + + p +When specifying the set of build-time dependencies, one +should list only those packages explicitly required by the +build. It is not necessary to list packages which are +required merely because some other package in the list of +build-time dependencies depends on them. The reason is +that dependencies change, and you should list only those +em/you/ need. What others need is their business. + /p + + p +It is a bug if, after unpacking a source package on a +system with the build-essential packages installed and +satisfying the build-time relationships (including the +implied relationships), one cannot build the package and +produce a working binary package suitable for installation +into the binary distribution corresponding to the source +distribution which contained the source package. This +means in particular that version clauses should be used +rigorously in build-time relationships so that one cannot +produce bad or inconsistently configured packages when the +relationships are properly satisfied. + /p + sect1 headingChanges to the upstream sources/heading --- packaging.sgml.orig Thu Aug 12 03:36:40 1999 +++ packaging.sgml Thu Aug 12 04:23:00 1999 @@ -1191,6 +1191,12 @@ (classification, mandatory) /p /item + item +p + qref id=relationshipsttBuild-Depends/tt at +al./qref (source package
Re: Bug#41232: AMENDMENT 1999-07-23 FINAL DRAFT] Build-time dependencies on binary packages
On Thu, Aug 12, 1999 at 03:43:27PM +0200, Roman Hodek wrote: You mean the target architecture? No. The dpkg-architecture terminology may confuse you. Here's from Packaging Manual 3.0.1.0 section 3.2.1 (debian/rules - the main building script): ... BUILD for specification of the build machine or HOST for specification of the machine we build for. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
The discussion period for this amendment ended on Friday, the 6th of August, 1999. However, we don't yet have a consensus. We do seem to be on the right track, though, so I'd like us to grant the one-time one-week extension to this discussion period. Thus the discussion should end on Friday, the 13th of this month. If this is not acceptable, the amendment should be marked as rejected. To concentrate the remaining discussion on the matters at hand, I'll summarise the points of disagreement and add my comments. * Are Build-Conflicts really necessary? - they appear to be, reading the current list of build-dependencies used by sbuild. * Do we need to conditionalize the build dependencies based on architectures? - Joel Klecker and Marcus Brinkmann seem to think so. I'm not convinced yet. - This would complicate the syntax * If so, what syntax should we use? - My choice would be the package (= 42 i386) syntax, as it's the least intrusive choice. * Should we use four fields or six fields? - In my opinion the four-field choice offers no real advantages (I've discussed my position in detail earlier) * When are versioned dependencies necessary? - Ian Jackson wants to allow the current stable as the base where versioned dependencies are not necessary - I've stated my position earlier: use versioned dependencies every time the non-versioned dependencies would introduce a possibility of a broken build, regardless of releases. I'd like us to reach a consensus on these points during the week we have left. If we can't, the proposal should be marked rejected. (And possibly a new, revised proposal sent out, if necessary.) I will be away for a few days starting from later today (Sat). -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
On Fri, Aug 06, 1999 at 05:00:27PM -0700, Joel Klecker wrote: Well, I *need* that to represent glibc's source depends correctly. Do you? It'd be rediculous for a Debian GNU/HURD system to need kernel-headers-2.2.10 to be installed for glibc's build depends to be satisfied, and equally rediculous for a Debian GNU/Linux system to need hurd-dev and gnumach-dev and mig(?). These packages share the common function of containing headers (?) for the kernel, be it Linux or the Hurd. Why is it then so appalling to have both package sets provide a suitable virtual package? (I will be easily converted to your ways if you just convince me of this point ;-) -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
On Sat, Aug 07, 1999 at 04:08:56PM +0200, Marcus Brinkmann wrote: Are you actually involved in any of our porting efforts? No, as I don't have the required hardware. or at least check one of the mailing lists frequently, to learn what is involved. I lurk on several Hurd lists, including debian-hurd. Don't forget that Debian is not Linux anymore I'm not forgetting that. But there is another point of trying to make sure Debian is as same as possible in its all incarnations, in one release. Architecture-dependent build dependencies can lead into forgetting that goal. (Could we agree on a phrase in policy in the style of don't use the architecture-dependent build dependencies unless you really have to?) Are you converted now? :) Possibly. I see your point and I trust that you wouldn't put this much effort to convince me if you didn't believe in what you're saying ;-) -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Bug#42554: A proposal for README.Debian
On Fri, Aug 06, 1999 at 11:59:38AM +0200, Stephane Bortzmeyer wrote: - the changes you made for the Debian package. How does this relate to the second paragraph of section 6.5 Copyright information? In addition, the copyright file must say where the upstream sources (if any) were obtained, and explain briefly what modifications were ^^^ made in the Debian version of the package compared to the upstream ^^ one. It must name the original authors of the package and the Debian ^^^ maintainer(s) who were involved with its creation. - the Debian packages you need to recompile this package. The Debian packaging system does not know about formal source dependencies. It will, soon. I don't think it is necessary to have the information duplicated in README.Debian. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Bug#42554: A proposal for README.Debian
Please, write shorter lines! On Fri, Aug 06, 1999 at 02:40:06PM +0200, Stephane Bortzmeyer wrote: I don't think we should write the Policy by taking into account changes which will be integrated in the next twenty years. Build-time dependencies can be implemented right now, as soon as we agree on the interface. There is an active policy proposal on this, go join the discussion. Seeing the buglist of dpkg, I seriously doubt that source dependencies will be implemented soon. You don't seem to understand the fact that build-time dependencies require only minimal changes to dpkg - and all this to scripts, the dpkg executable need not be changed. I have already produced a patch based on an earlier version of the interface draft. And actually, build-time dependencies are already implemented in the sbuild daemon. While a change in the Policy's Documentation section is much lighter. It's about as light as my build-time dependency proposal. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Re: /usr/share/doc vs. /usr/doc transition, debate reopened
On Fri, Aug 06, 1999 at 02:30:51AM -0300, Nicolás Lichtmaier wrote: Why do you think that we couldn't make a decision now? Because we haven't been able to do so in the last few weeks. And will those reasons go away in the future? Perhaps. Perhaps not. But if it is indeed harmful for people to move to /usr/share/doc now, ten policy should not mandate it now. (Of course this is all academic now as the technical committee has been invoked.) -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Bug#42554: A proposal for README.Debian
On Fri, Aug 06, 1999 at 03:04:13PM +0200, Stephane Bortzmeyer wrote: I've missed this line, sorry. Isn't it strange to have technical information like this one in a copyright file? Not at all. Changes made to a program are very much an issue of copyright. Who will have the idea to read here? Everybody who knows Debian policy. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
On Wed, Aug 04, 1999 at 04:02:14PM -0700, Chris Waters wrote: + pFor the release code-named Potato, packages should + continue to use /usr/doc instead of the FHS's + /usr/share/doc, for consistency. For uploads to + Potato (and the earlier Slink), please use + /usr/doc whereever this document refers to + /usr/share/doc./p Seconded. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail
On Thu, Aug 05, 1999 at 01:10:35PM -0400, Johnie Ingram wrote: Ian What does dpkg do in the case of circular dependencies? It dies a horrible, violent death No it does not. -- see Bugs 22999, 23611, 23906, 24626, 24690, 24923, 26084, 29901, 34136, 34174, 34287, 38155, 38288, 38378, 38381, 38393, 38754, 39204, 39275, 41611, and of course 41808. These bugs manifest themselves in certain special situations (either a self-dependency or a dependency cycle involving a virtual package). Most of the time dependency cycles are OK. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Re: /usr/share/doc vs. /usr/doc transition, debate reopened
On Tue, Aug 03, 1999 at 09:52:04PM -0300, Nicolás Lichtmaier wrote: The policy was immature. Shouldn't the decision be undone for now, then? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Re: Let's just convert debhelper and do NMUs
On Wed, Aug 04, 1999 at 12:29:29AM +0100, Julian Gilbey wrote: why don't we follow the Perl team's lead I most definitely agree with your plan. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Re: Let's just convert debhelper and do NMUs
On Wed, Aug 04, 1999 at 01:31:09AM -0400, James Mastros wrote: Con: There will be a period where some packages use usr/doc and some usr/share/doc, confusing users. Reply: It's called unstable for a reason. ... and that period is already here. Con: All packages will have to depend on a base-files with a usr/share/doc/ directory. Why? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Re: FWD: /usr/doc vs. /usr/share/doc - the decision
On Tue, Aug 03, 1999 at 11:11:45PM -0700, Joey Hess wrote: Thus, I would like to encourage everyone to wait until this issue is resolved or until we agree there is no good resolution, before implementing the current policy of making packages use /usr/share/doc. Here's what I'll do: * I recognise the problems, so I will not upgrade to policy 3.0 any more packages * However, I will not revert the changes I already have made to my packages, unless policy is changed to say I have to. I encourage the policy group to consider it a mistake to mandate the move prematurely, and to undo the change wrt /usr/doc (not the whole FHS, though), until a solution is found. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Re: Let's just convert debhelper and do NMUs
On Wed, Aug 04, 1999 at 02:05:31PM -0400, James Mastros wrote: Beutiful... so we're already implementing this. Current policy specifies /usr/share/doc . -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Re: /usr/share/doc vs. /usr/doc transition, debate reopened
On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote: IMHO, packages that started using /usr/share/doc were premature in that usage Your opinion is wrong. Those packages follow current policy. Not using /usr/share/doc in a standards-version = 3.0.0 package is a policy violation. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Re: /usr/share/doc vs. /usr/doc transition, debate reopened
On Tue, Aug 03, 1999 at 09:22:27AM -0400, Michael Stone wrote: Sure it's legal, but was it a good idea? You could ask the same question from a different perspective: was it a good idea to change policy to use /usr/share/doc before the transition was hashed out? And is it a good idea to leave it that way? Perhaps the change should be reverted until we have a solution. Do you want to argue that the current state of the distibution is a Good Thing? Well, I don't see any grave problems in having docs in two different places. No essential part of the system breaks by that, it just causes some minor inconvenience. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Re: /usr/share/doc vs. /usr/doc transition, debate reopened
On Tue, Aug 03, 1999 at 12:11:21PM -0400, Michael Stone wrote: If people would have some patience to wait for a consensus, we could do this with less argument, IMHO. It should be possible for a developer to trust the policy documents. If they don't reflect the consensus, the policy document should be changed. I'm not reverting my packages as long as policy dictates /usr/share/doc. The issue is not that critical. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Re: /usr/share/doc vs. /usr/doc transition, debate reopened
On Tue, Aug 03, 1999 at 09:53:24AM -0700, Joseph Carter wrote: Those people now wanting to undo the change had plenty of opportunity to cause the change to never happen in the first place. Are you saying I should be actively violating Policy? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% ... memory leaks are quite acceptable in many applications ... (Bjarne Stroustrup, The Design and Evolution of C++, page 220)
