Re: PW#5-12: New upload procedure
On Thu, 3 Dec 1998, Julian Gilbey wrote: On Fri, 20 Feb 1998, Christian Schwarz wrotee, while discussing the proposed (and agreed upon) changes to dpkg-genchanges and dinstall to make the closing of bugs etc. run more smoothly: Another suggestion was to change the Maintainer: field to Developer:, Uploader: or whatever, since this field does not list the actual maintainer taken from the control file, but the person listed in the changelog entry (who might be someone else than the Maintainer of the package, e.g., for NMU's). Opinions? There did not appear to be any replies at the time. I intend to make the required changes to the relevant scripts over the next few days, so if we could reach a decision on this point, it would be great. I like the term Uploader, for the person who did the upload. -- 00f99feec90136eb38bbb6632b26282c (a truly random sig)
Bug#29770: Policy contradicts itself about /etc/aliases
On 28 Nov 1998, Manoj Srivastava wrote: Since /etc/aliases is not a conf file belonging to any package whatsoever, sectiosn 4.7 and 5.5 are not in conflict. I am closing this report. Please, read carefully the bug report. Policy says: A package may not modify a configuration file of another package. but /etc/aliases is certainly a configuration file for sendmail. It does not say a conffile in the dpkg sense, it says a configuration file. If policy says a configuration file but it should say just a conffile then policy should be clarified, at least. I still think this is a little inconsistency that should be fixed to avoid confusion. -- d727d8acee49b053575a7ebca9668994 (a truly random sig)
Re: priorities and package relations
On Sat, 28 Nov 1998, Wichert Akkerman wrote: A while ago someone (Santiago iirc) filed a bugreport about packages depending on other packages with a lower priority. This made me wonder about allowed relations between packages. Reading the policy document does not give any explicit demands. The only thing that I am sure of is that a package may not depend on a packages with a lower priority. If this also holds for recommends is not specified, although it might be logical considering that a Recommend is handled the same as a Depend with respect to DFSG compliance. I have updated my dependency-checker to also check Depends for priorities, and the report is available via www at http://master.debian.org/~wakkerma/unmet.html . Good work! Yes, a Recommends should be treated the same as a Depend with respect to DFSG compliance. [ You will find this in policy 2.5.0.0, section 2.1.2, The main section ]. Also, packages in the base system (i.e. those in base2_1.tgz) should not require a package outside of the base system to work, because otherwise the base system would be broken. Whether this requires is just Depends or both Depends and Recommends I don't know (if you are going to write a dependency checker for that, you may try both and see what happens, there are not many packages in the base system). If this is not policy yet, maybe we should make it policy. Also, since optional means all the software that you might reasonably want to install if you didn't know what it was or don't have specialised requirements, and since the user will not reasonably want to install packages that conflict at each other, I think we should consider a big mistake that we ship package A and package B if both A and B are optional but one of the two conflicts with the other. Again, if this is not written in the policy yet, maybe it should, IMHO. Thanks. -- 17c2d6170cc60beb55fb5f360c5e2d84 (a truly random sig)
Bug#29770: Policy contradicts itself about /etc/aliases
Package: debian-policy Version: 2.5.0.0 I have discovered a little inconsistency in the policy. Section 5.5, Mail transport agents says: /etc/aliases is the source file for the system mail aliases (e.g., postmaster, usenet, etc.)--it is the one which the sysadmin and postinst scripts may edit. According to this, a postinst script *may* edit /etc/aliases. However, section 4.7, Configuration files says: A package may not modify a configuration file of another package. According to this, editing /etc/aliases is not allowed, since this file is a conffile for sendmail, at least, and certainly it is a configuration file in either case. So, which is the truth, may /etc/aliases be edited by a postinst, or it may not? If do not modify a configuration file of another package is just a general rule, it should be clear how many exceptions to the rule are there. Thanks. -- 85438ed58b89b28d0dec167b46f14221 (a truly random sig)
It is ok to have a hardcoded Depends: libc6-dev ?
Hi. We have the shlibs mechanism for dependencies on shared libraries. This allows a package to be compiled under libc5, libc6, or whatever libc, and the right dependency info will be calculated automatically. However, there are some packages having a hardcoded dependency on libc6-dev, and it seems there is not a shlibs mechanism for that. I ask this because GNU/Hurd does have glibc2 and glibc2-dev (instead of libc6 and libc6-dev). We will have an shlibs file for glibc2 so that Depends: glibc2 lines will be automatically generated by the shlibs mechanism. But we will have to change all the hardcoded libc6-dev dependencies by hand. We can, of course, make glibc2-dev to provide libc6-dev (and we will probably have to do that as a workaround in the meantime). However, I feel this is not the right thing to do. So: It is ok that a package depends on libc6-dev in a hardcoded way, should that package depend on libc-dev instead, or is there (or should be) any other way to do this in an elegant way? Thanks. -- 5d236d7fa19df5d32a672156150c911c (a truly random sig)
Bug#17621: PROPOSED]: About versions based on dates
On 30 Oct 1998, Manoj Srivastava wrote: Native Debian packages (i.e., packages which have been written especially for Debian) whose version numbers include dates should always use the `-MM-DD' format. James Troup pointed out some time ago that this probably breaks another policy about version numbers in native Debian packages. [ That's why the debian-keyring package he maintains uses dots instead of hyphens, .MM.DD ]. I am now looking for seconds for this proposal. I would propose to discuss this minor point first. [ I would suggest to make MMDD the recommended choice in this case, points are not allowed in ISO dates, only hyphens or nothing, I think ]. -- cd3d0d19223690be5e8d03f02a40e647 (a truly random sig)
Re: Installing files in user directories
On Thu, 22 Oct 1998, Steve Greenland wrote: In either case, get rid of the .bashrc. If root wants an example, there's always /etc/skel. Heck, if you want to copy dot.profile and dot.bashrc to /root, no problem. Just stop screwing with the files that are actually used! Well, .bashrc is not just an example, it is now sourced by .profile :-) This is more a reasonable default than an example. No, it's not, because there is no reason for it to be in .bashrc. Instead, please put both those commands in .profile, where they belong, and get rid of the .bashrc. I do not plan to get rid of .bashrc, because it contains example aliases. aliases are better in .bashrc than in .profile, because they are not inherited from one shell to another one. I would be willing to modify base-files.postinst so that it install dotfiles for root *only* when it is not being upgraded (i.e. when creating the base system which is being shipped in base2_0.tgz). I would like that. Hell, I'd settle for the postinst just *asking* if I want to write a .profile and .bashrc (on an upgrade). No, policy says that asking should be avoided unless absolutely necessary. (And we have already too many questions in upgrades). If I have to ask the user about root's dotfiles, then I would better modify base-files so that these files are only provided in base2_0.tgz. (i.e. only when you are not upgrading the package). But before that I would like to be sure that this new behaviour is supported by all the policy people here, and that reinstalling base-files did not fix my PATH should not be considered a bug anymore. Obviously, I agree. Ok. Does the rule reinstalling a package should be idempotent apply to base-files? If that applies, then you should *always* overwrite the .profile, right? No, because it is a configuration file. I was referring to the fact that if something goes wrong (and not having a dotfile which ensures that root has the proper PATH is wrong in some sense), reinstalling a package should ideally fix the problem. But I think you have a valid point here. If you decided to move the setting of the PATH for root from dotfiles to /etc/profile, you should have the right (and the freedom) to do so, and I don't think base-files should force people to create empty dotfiles if they do not want to have the default ones. So unless somebody strongly objects and tells me that this is a really bad idea, I will modify base-files so that it installs default dotfiles only for the base system (base2_0.tgz), i.e. when it is not an upgrade. base-files will assume from now on that the user knows what he/she is doing with root's dotfiles and will not try to be more clever than the user. We have to take in account also that: 1) If all the dotfiles disappear from /root, the default PATH will be then the one in /etc/profile, which is supposed to be sensible enough, it may be not suitable for root, but it is not a security risk, after all. 2) The default dotfiles will be still available in /usr/share/base-files. If somebody loses his dotfiles and wants the default ones again, he/she will be able to copy them from that directory. If needed, I will document this in /usr/doc/base-files/README. Thanks. -- 00df38a60d65b6024086095137a36e4f (a truly random sig)
Re: Installing files in user directories
On Wed, 21 Oct 1998, Steve Greenland wrote: Here are some problems with the current solution: 1. Who said that root's home dir is /root? The /etc/passwd file as provided by base-passwd. If you modify root's home dir, you break the base-passwd package, since root is a user who belong to the system, not to you. 2. If I deleted my .profile and .bash_profile and (whatever) from ~root, that's what I wanted to do. I don't want them replaced. I fail to see why you want to break your system in that way. As I said before, some time ago I received a bug report from someone who lost his .bash_profile file, and he said that installing base-files again did not help in fixing the PATH. Policy says that reinstalling a package should be idempotent so that this type of bug may be easily fixed by simply reinstalling the package. You seem to be the only one who wants to remove all your root dotfiles. There is an easy workaround for you: Just create empty files and they will not be replaced at all. 3. There way more ways for root to screw things up. This is a pretty limited fix. I suspect it's far more like for the novice user to screw up his/her .profile in vi than to rm it completely. Well, I encountered a user that removed it completely. Here's what I'd like to see: 1. Put root's PATH and umask 022 in /etc/profile, where it belongs. I think that root's PATH is special and belong to root's dotfiles, not to /etc/profile. or 2. Provide some sort of prompting *before* you copy the default .profile (and only if none of the potential startup files are there, either by hand or via the conffile mechanism (better). No, the conffile mechanism is *not* better in this case, because if you have no file, dpkg thinks that you do not want *any* file, which is not what one would normally want, because then we have the PATH problem, that's why these dotfiles are not conffiles anymore. In either case, get rid of the .bashrc. If root wants an example, there's always /etc/skel. Heck, if you want to copy dot.profile and dot.bashrc to /root, no problem. Just stop screwing with the files that are actually used! Well, .bashrc is not just an example, it is now sourced by .profile :-) This is more a reasonable default than an example. I would be willing to modify base-files.postinst so that it install dotfiles for root *only* when it is not being upgraded (i.e. when creating the base system which is being shipped in base2_0.tgz). [ Maybe this is the best solution, I agree ]. But before that I would like to be sure that this new behaviour is supported by all the policy people here, and that reinstalling base-files did not fix my PATH should not be considered a bug anymore. Does the rule reinstalling a package should be idempotent apply to base-files? -- 566100428febf3fbaeae13c676b98e06 (a truly random sig)
Re: /etc/adjtime, /etc/timezone, etc.
On Mon, 19 Oct 1998, Ian Jackson wrote: Are the additional things I said in my last message about this sufficient for you to clarify the policy ? I think they are not sufficient. Maybe I should propose an amendment to the current text. -- 3bfc2ca36032b30f1040093bfee1f3ea (a truly random sig)
Re: FHS - transition
On 17 Oct 1998, Adam P. Harris wrote: Santiago Vila [EMAIL PROTECTED] writes: [...] They are not just things that would be nice to have implemented (wishlist). We really *need* to have them fixed in the near future. Otherwise we will never move to FHS. Woah there, one step at a time. I'd like to see (a) a proposed appendix to the Packaging Manual about handing the FSSTD-FHS issue, or else a separate file in the packaging-manual package; and finally (b) general consensus, i.e., this is the best way to do it on (a); and finally, (c) a proposed policy amendment. Only once all that is done, can we start filing serious bugs. Ok, this sounds very reasonable to me. Clearly we need a general consensus, and clearly we do not have such thing (yet). Thanks. -- 892ac5187008c4c2822d384603ab119c (a truly random sig)
Re: Installing files in user directories
Hi. Maybe you are simply surprised by the fact that base-files recently changed from installing a default /root/.bash_profile to installing a default /root/.profile (which is slightly more POSIX). I considered several ways to do this. Among them: 1. If ~/.bash_profile exists and ~/.profile does not, move automatically ~/.bash_profile to ~/.profile. 2. If neither ~/.bash_profile or ~/.profile exists, install a default ~/.profile. 3. If neither ~/.bash_profile, ~/.bash_login or ~/.profile exist, install a default ~/.profile. 4. If ~/.profile does not exist, install a default ~/.profile. I chose 4. because it is the simplest solution. bash first looks for .bash_profile, then .bash_login and then .profile, and executes the first one that exists and is readable. Therefore if the user has already a working .bash_profile and base-files installs a default .profile, it will be completely harmless. I could implement 2) or 3) instead, but it is really needed? -- 697b299e5c84f28eb38b37da74759b89 (a truly random sig)
Shipping .texi sources in binary packages (was: unidentified subject)
( Sorry for replying so late, the old Subject was not very appealing :-) On 23 Sep 1998, Manoj Srivastava wrote: I suggest that the preferred source format of the documentation be also available. This means that we also ship texinfo, tex, and sgml versions of the documentation, as well as HTML formats (we may also ship man, info, ps formatted documentation too, but the source and HTML should always be there). I would like to say that after modifying some of my GNU packages to ship the docs in HTML format, I dislike very much the idea of modifying the policy to ship the .texi source too. The problem I encountered was the following: I first planned to modify my debian/rules files so that a symlink for the .texi source is created from the debian/tmp/usr/doc/package-doc directory to the real file. Then it would be just a matter of cd debian/tmp/usr/doc/package-doc texi2html -options foo.texi and removing the foo.texi symlink afterwards. Well, this didn't worked, because the .texi file included sometimes another files like version.texi and such. Therefore I had to create the html in place and move it to debian/tmp/usr/doc/package-doc afterwards. Some people propose that we ship .texi source in binary packages, but this means that we would have to identify *all* those extra files that are needed to generate the .html. This is a lot of (unneeded) work, IMHO. So shipping the .texi source will not be as easy as some people think, since there is not always a *single* file containing the source. Sometimes there is even a Makefile to build the docs. Are we going to ship a Makefile too? It seems to me that the general rule that source belongs to the source package should apply here. We should already ship .html as this is our preferred documentation format (at least policy says so). Do we really need to make things more complex than they are now? Why don't we concentrate instead in finding a standard procedure for registering html docs, our (already) preferred documentation format? Thanks. -- cccf08cbc9ee0529a5daf71e890f0901 (a truly random sig)
Re: Shipping .texi sources in binary packages (was: unidentified subject)
On 20 Oct 1998, Manoj Srivastava wrote: Santiago So shipping the .texi source will not be as easy as some Santiago people think, And not as hard as some people think either. He, he, we are close to repeat the bash-essential discussion here ;-) -- 8460b24dc2ac9d46432ccd8965300fbe (a truly random sig)
Re: Shipping .texi sources in binary packages (was: unidentified subject)
On 20 Oct 1998, Manoj Srivastava wrote: Santiago It seems to me that the general rule that source belongs to Santiago the source package should apply here. No. HTML is not a good format for printing. dvi files are not quite as portable as one would like (due to font issues) The purpose of shipping the docs in binary packages is to made them available to be read, not to be printed. (BTW: What font issues are you talking about?) Santiago We should already ship .html as this is our preferred Santiago documentation format (at least policy says so). Do we Santiago really need to make things more complex than they are now? Yes. With SGML, I can choose plain text, HTML, tex, postscript, or another SGML DTD. This is functionality that is not crrently guaranteed. I don't understand. Do you propose that .sgml replaces .html as our preferred documentation format in the long run? Do you propose to convert all .texi to .sgml? Santiago Why don't we concentrate instead in finding a standard Santiago procedure for registering html docs, our (already) Santiago preferred documentation format? That too is a useful thing to have. So is an easy way of generating nice, printable, documents. I should not have to download the whole source just for a teeny .texi or .sgml file. Well, .texi are not usually very tiny either. We could make them available via uploads, but without including them in any binary-package (using byhand in the .changes file). and we could have some doc tree at ftp.debian.org and a tool to retrieve the latest source from a given package. If we include the .info, the .html and the .texi in binary packages, I'm afraid we will the first Linux release to require DVDs for distribution. -- dcc79389fecd3d1b91c8f4202c6d8361 (a truly random sig)
Bug#27906: PROPOSED] Binary-only NMU's
Ian, before you propose a complete reorganization of our FTP archive to comply with the GPL, please take a look at the SOURCES file in the GNU operating system, version 0.2. Some excerpts: *--- Sources for binaries in GNU version 0.2. Typical configure line is ../../src/foo-NN/configure --prefix= --cache-file=../config.cache i486-gnu [...] cvs (1.9) [ inhibit use of libc getopt by defining _LIBC in lib/getopt.c and lib/getopt1.c immediately before it is tested. ] [...] findutils (4.1) [ Comment out basename in find/defs.h and find/util.c. Define _GNU_SOURCE at front of find/pred.c. Define ARG_MAX to be 20480 before its first use. ] [...] gzip (1.2.4) [ Comment out basename in gzip.h and util.c. ] [...] *- GPL says: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. Ok, what happens if the compilation is not done entirely by scripts, but with a combination of scripts + manual hacking, as described by this file? Do we always have to compile something by scripts? [ Today I have uploaded four packages for hurd-i386, in all the four cases I have hardcoded the Depends line by hand, because we have not a working cross-dpkg-shlibdeps among our cross-compiler tools yet. The day we have one, the end result will be the same. Would I be violating some license if the package were GPLed just for not providing a patch somewhere? ]. Is the FSF violating its own license by describing with words how to compile the various packages in the GNU system? -- 72af48bcad139b59857329e82270e80a (a truly random sig)
Re: /etc/adjtime, /etc/timezone, etc.
On Mon, 5 Oct 1998, Ian Jackson wrote: Santiago Vila writes (Re: /etc/adjtime, /etc/timezone, etc.): ... Of course it is possible. But the reason policy says some files should not be conffiles is the following: Doing this will lead to dpkg giving the user confusing and possibly dangerous options for conffile update when the package is upgraded., which is completely false for conffiles that never change (I mean: conffiles for which the package provided version is always the same). Therefore, if we want to encourage the creation of certain files in the postinst (as opposed to being them conffiles), we need a better rationale (see my bug report, #26402). Firstly, in situations where a conffile file is created by a script before dpkg gets to it, dpkg will still prompt. Yes, but I was talking about creation of certain files in the postinst as opposed to being them conffiles. Secondly, you can't guarantee that the file in the package will never change. I can't guarantee anything, because free software comes with no warranty :-), but if I never change the file in the package, then the file would never change (as it is happening with /etc/timezone so far). Why can't you just handle this in the postinst, without involving dpkg ? Of course I can, I've already done this (in base-files_2.0.1), but I still think policy needs a little bit more of rationale. I see it is better, you see it is better, and Manoj sees it is better, but policy does not explain well enough (IMHO) why it is better, it does not contemplate all possible cases. BTW: Please, Cc: me when replying if you do it one month after my last post, I almost missed this message :-) -- 68340b7f29bea02be84b717c47a6c0a1 (a truly random sig)
Re: FHS - transition
On 16 Oct 1998, Adam P. Harris wrote: Santiago Vila [EMAIL PROTECTED] writes: On 10 Oct 1998, Adam P. Harris wrote: 2. info browsers, manual pagers, terminfo libraries, etc., are Yes, but where is the info program that looks in both directories? Before saying this must be done in this way I would like to be sure that effectively it may be done and someone will do it. What possible assurance could I give you? I think, say, filiing important bugs on the relevant packages would suffice to ensure that the issue is fixed prior to the release. Clearly I'm not proposing to do this now -- no, only once we've resolved to transition (gently) to FHS. Ok, could we then upgrade those bugs to normal at least? They are not just things that would be nice to have implemented (wishlist). We really *need* to have them fixed in the near future. Otherwise we will never move to FHS. -- 7e25cd22813969f6354a72747fa151a9 (a truly random sig)
Re: FHS - transition
On Thu, 15 Oct 1998, Ian Jackson wrote: We have discussed this before, but it seems that you missed the discussion at all: If man and info are modified so that they support both old and new locations, we will not have to symlink anything, and we will not need to copy a lot of files from a directory to another one. Just upgrade packages incrementally and the ones being FHS-compliant will have already the files in /usr/share. This will mean that in order to read manpages from new packages it will be necessary for the user to use a new manpage program. Exactly. Better having to upgrade the manpage program than upgrading base-files, which has nothing to do with manpages. This is precisely the kind of incompatibility I want to avoid. I don't think anything really bad will happen if we modify info and man for Debian 2.2 so that they accept both FSSTND and FHS locations and wait for Debian 3.0 to be fully FHS compliant. This way the user would only need to install a new version of the manpage program if he/she is using Debian 2.1 and wants to install a certain package from Debian 3.0. This is unlikely to happen. My scheme works fine if you don't want to copy things. We can just leave them in the old place, with a symlink, forever, if we want. Well, it depends on what we understand by works fine. For me, it would be very very ugly indeed to have things in the old place forever. It is not enough that we find the docs in /usr/share/doc in a Debian system to be FHS compliant. It is necessary that every package is FHS compliant, so that they may be installed also in another FHS system, without problems. We can not rely on strange symlinks being there forever. I don't think it would be true if we say that our system is FHS but our individual packages are not. For this reason I'm definitely think that making symlinks from the *new* place to the *old* one in the FHS transition (first item in your proposal) is not a good idea. However, making symlinks from *some* of the *old* place to the *new* ones is not such a bad idea, and I'm really considering it. What I have in mind is this: * For info: base-files_2.1 does not have /usr/info anymore but /usr/share/info. Its postinst checks for the existence of /usr/info and if it is a real directory it moves its contents to /usr/share/info. If /usr/info does not exist yet, then base-files is being installed by the boot-floppies script to make the base2_1.tgz base system. In this case there is nothing to move. Last line in base-files postinst would then create a symlink from /usr/info to /usr/share/info, so that dpkg follows the symlink for all newly installed packages. This would make modifying the info program unnecessary, and also I would not have to coordinate with the info maintainer about the /usr/info/dir file, which base-files has to create if it does not exist (how will base-files know where to create the default dir file if the info program is able to read two different (real) directories?). Moreover (this is important), /usr/info/* is not usually very large. * For man: base-files_2.1 would have both /usr/share/man and /usr/man as real directories. As far as I know, no modification is required in our standard man program itself, because its behaviour is driven by a configuration file, /etc/manpath.config. So we could have both /usr/share/man and /usr/man at the same time and nothing bad would happen. We would only need the mandb package to be modified so that its default config file includes the old and the new locations. Summary: With a very little change in base-files and a very little change in mandb, we could make Debian 2.1 to be the first Debian release to support FHS-paths for manpages and info files, so we could make policy for Debian 2.2 that all manpages and info files should be already installed in the new locations. What do others think about this? -- 32499857f009b9b64b41f10cd74b34c7 (a truly random sig)
Re: FHS - transition
On 10 Oct 1998, Adam P. Harris wrote: 2. info browsers, manual pagers, terminfo libraries, etc., are Yes, but where is the info program that looks in both directories? Before saying this must be done in this way I would like to be sure that effectively it may be done and someone will do it. The only sticky point, really, is /usr/doc. Moving that to /usr/share/doc is going to be difficult. Maybe we could just avoid that? Installing new FHS-compliant packages that replace the old ones should be enough. -- 0fa2a35aa19662d3536943decf0fd77d (a truly random sig)
Re: FHS - transition
On Tue, 6 Oct 1998, Ian Jackson wrote: (See also my post to debian-devel about this. In particular, I'm opposed to /var/state and think we should ignore the FHS on this point.) One of the key changes that the FHS has compared to the FSSTND is the existence of /usr/share. I think this is perfectly appropriate, but it will take some effort. We need to make sure that everything works during the transitional period. The following things should be done in the following order: 1. base-files should be amended to contain /usr/share/man, /usr/share/doc and similar, as symlinks to /usr/man, etc. base-files's postinst should check that none of these directories exist as actual directories in both places and fail with an error message if they do. [ snipped ] I strongly disagree. In fact, I see this as a contradiction to your earlier post, in which you said: no `flag day', no moving everything at once. We have discussed this before, but it seems that you missed the discussion at all: If man and info are modified so that they support both old and new locations, we will not have to symlink anything, and we will not need to copy a lot of files from a directory to another one. Just upgrade packages incrementally and the ones being FHS-compliant will have already the files in /usr/share. -- 793d082717ed6f2004f4cbe783e80b1d (a truly random sig)
Re: /usr/local in some packages
On Tue, 29 Sep 1998, Herbert Xu wrote: After purging emacs today, the damn thing deleted my /usr/local symlink since it was the last package to have /usr/local in it. Obviously this is not very clever. Would have this happened if base-files contained /usr/local as an empty directory? Since dpkg follows symlinks, you would be able to remove /usr/local, create a symlinks, and you would be still able to upgrade base-files without problems. Also, in the case /usr/local is a read-only partition, would dpkg give an error when overwriting (overlapping, really) an empty directory by the one provided in the package? If not, I think this could be a solution to this problem. -- da5756474c9bb42366c62ebc9b970ab7 (a truly random sig)
Re: /usr/local in some packages
On Tue, 29 Sep 1998, Herbert Xu wrote: On Tue, Sep 29, 1998 at 01:28:27PM +0200, Santiago Vila wrote: On Tue, 29 Sep 1998, Herbert Xu wrote: After purging emacs today, the damn thing deleted my /usr/local symlink since it was the last package to have /usr/local in it. Obviously this is not very clever. Would have this happened if base-files contained /usr/local as an empty directory? Well, maybe. But then people may start using /usr/local/lib and you will end up adding that to base-files and maybe even more. Well, no, the thing would stop at /usr/local. You should not be forced to have anything inside /usr/local. But yes, I agree it is not needed at all. Just fix emacs20, it's already reported as Bug #23431. -- 26c03c8e40511060460d97e1faa16a07 (a truly random sig)
Re: {PROPOSAL} #7890: Policy manual contradicts itself about including docs
On 21 Sep 1998, Manoj Srivastava wrote: - ship HTML versions in the binary package, in the directory - /usr/doc/package or its subdirectories. + ship HTML versions in a binary package, under the directory + /usr/doc/appropriate package or its subdirectories. I second this. It reflects the fact that they must be available in some package, but does not forbid it to be in a different package, so this way policy will be consistent and will not contradict itself anymore.
Re: Call for Seconds, Take II
On Mon, 14 Sep 1998, Zed Pobre wrote: + this string is reserved for the GNU Hurd operating system. GNU/Hurd [ I think everyone will agree on this ]. Thanks. -- 60bd5544e9f94328d8d2823b5dc2452e (a truly random sig)
Re: Comments on policy modifications
On Tue, 15 Sep 1998, Marcus Brinkmann wrote: On Mon, Sep 14, 1998 at 10:00:36PM +0200, Santiago Vila wrote: On Mon, 14 Sep 1998, Marcus Brinkmann wrote: So should we change i386-hurd to i386-gnu on the ftp archive? This would also express the explicit wish of Gordon, IIRC. I don't think this is strictly necessary, it would add confusion to our users, which would ask over and over again about this gnu thing (is not linux gnu also?). BTW: On the ftp archive we have hurd-i386, not i386-hurd. True. Seems that I'm completely confused by the architecture string opposed to the name the architecture carries on the ftp site. Are they at all related? Well, this is the current situation: dpkg architecture Architecture string (for configure scripts) field (for FTP) i386i386-linux alpha alpha-linux powerpc powerpc-linux [...] [...] hurd-i386 i386-gnu They are related in general, just that GNU/Hurd is a special case. To be consistent, we would have to rename i386 to i386-linux in the FTP archives, but I don't think this is necessary either. As soon as Linux binary compatibility is achieved, hurd-i386 could become just a subtree of i386 (like amigas and ataris for m68k). -- ceedd9d840a610bdcbb8b6b91fa93422 (a truly random sig)
Re: Comments on policy modifications
On Mon, 14 Sep 1998, Zed Pobre wrote: In the mean time, then, if I understand correctly, the only arch string that will allow proper compilation is i386-gnu? Yes, because the gnumach kernel does only work under intel currently. -- 136b152ac3c4c1d999f0afddbbb9c284 (a truly random sig)
Re: Comments on policy modifications
On Mon, 14 Sep 1998, Marcus Brinkmann wrote: On Mon, Sep 14, 1998 at 05:24:25PM +0200, Santiago Vila wrote: On Mon, 14 Sep 1998, Zed Pobre wrote: In the mean time, then, if I understand correctly, the only arch string that will allow proper compilation is i386-gnu? Yes, because the gnumach kernel does only work under intel currently. So should we change i386-hurd to i386-gnu on the ftp archive? This would also express the explicit wish of Gordon, IIRC. I don't think this is strictly necessary, it would add confusion to our users, which would ask over and over again about this gnu thing (is not linux gnu also?). BTW: On the ftp archive we have hurd-i386, not i386-hurd. On the contrary, we may consider the architecture-specification string i386-gnu as an historical accident, and we as developers, can live with it. -- 80cae37290ee81b8d5b51bb0663dc5ef (a truly random sig)
Re: Call for seconds: Policy modifications
On Sun, 13 Sep 1998, Richard Braakman wrote: Zed Pobre wrote: Part 3: (bug#25385) Section 4.1 (Architecture specification strings) should be changed to allow the Hurd operating system. This requires that the segment reading: where `arch' is one of the following: i386, alpha, arm, m68k, powerpc, sparc. be changed to: where `arch' is one of the following: i386, alpha, arm, gnu, m68k, powerpc, sparc. This is wrong. It would add gnu-linux as an architecture. What is needed is to add arch-gnu to arch-linux, for all architectures. (Currently there is only an i386 port, but that may change). Hi. Richard is right. The bug report means that whenever arch-linux is allowed, arch-gnu should be allowed also (even if only i386-gnu is used for now). This arch-linux or arch-gnu thing (Architecture specification strings) is the type of argument we pass to autoconf-generated configure scripts. I find it amusing that the FSF contradicts its own GNU/Linux stance here :-) Apparently linux is GNU/Linux, but the Hurd is called gnu to distinguish it from linux. I would find an architecture string with hurd to be far more consistent. Probably, but I'm afraid it's too late to change that. -- 08aca8c29c6c02b3ad35ddbd47eddec5 (a truly random sig)
Re: /etc/adjtime, /etc/timezone, etc.
On 4 Sep 1998, Manoj Srivastava wrote: Santiago But the reason policy says some files should not be Santiago conffiles is the following: Doing this will lead to dpkg Santiago giving the user confusing and possibly dangerous options Santiago for conffile update when the package is upgraded., which Santiago is completely false for conffiles that never change Well, I guess a rationale is that saying `never' anything is dangerous [...] Yes, this could be some of the rationale I would like to see. I hope not to be misunderstood. I *agree* with you that the postinst solution is probably better, my only complain is that policy (currently) does not give a rationale which is good enough for all cases yet. -- 895004c4c3b4106584e9be1299f8183c (a truly random sig)
Re: A mechanism to amend policy documents
On 5 Sep 1998, Manoj Srivastava wrote: Do you not find the version numbers suggestive? debian-policy_2.4.1.3.deb developers-reference_2.4.1.3.deb packaging-manual_2.4.1.1.deb Would there be serious objections to having the policy maintainers actually take over the developers reference? I have nothing to object. The fact that they are purely documentation does not necessarily mean that having the policy maintainers to take them is a bad idea. -- 09459a284629d79f054660542c36558d (a truly random sig)
Re: /etc/adjtime, /etc/timezone, etc.
Ok, I will answer myself :-) I have found a paragraph in the packaging manual providing the rationale for not making conffiles certain files. However, the given rationale is not enough when the conffile is always the same, so I have just submitted a bug against debian-policy asking for more rationale and/or a clarification. [ hope this is the right thing to do ]. Thanks. -- 2429bfba804d9f31ae3acbd9484ed134 (a truly random sig)
Re: /etc/adjtime, /etc/timezone, etc.
(thanks for answering :-) On 4 Sep 1998, Manoj Srivastava wrote: Santiago Ok, I will answer myself :-) I have found a paragraph in Santiago the packaging manual providing the rationale for not making Santiago conffiles certain files. However, the given rationale is Santiago not enough when the conffile is always the same, so I have Santiago just submitted a bug against debian-policy asking for more Santiago rationale and/or a clarification. [ hope this is the right Santiago thing to do ]. Is it possible then to handle the situation totally in the postinst? Of course it is possible. But the reason policy says some files should not be conffiles is the following: Doing this will lead to dpkg giving the user confusing and possibly dangerous options for conffile update when the package is upgraded., which is completely false for conffiles that never change (I mean: conffiles for which the package provided version is always the same). Therefore, if we want to encourage the creation of certain files in the postinst (as opposed to being them conffiles), we need a better rationale (see my bug report, #26402). In general, one may have /usr/doc/package/conffile.example.gz; and the postinst merely copies and unzips as needed. [ Minor nitpick: No package should ever reference anything in /usr/doc. Use /usr/share/package instead ]. -- 77a9331e1254319fddab90050369b582 (a truly random sig)
/etc/adjtime, /etc/timezone, etc.
[ Please don't Cc:me, I will read your input in the list ] Hi. In bug #23255, Nicolás Lichtmaier reports that /etc/adjtime should probably not be a conffile (i.e. a configuration file managed by dpkg through the conffile mechanism), and he cites policy to support this. However, since the default /etc/adjtime in the package does never change, its md5sum does never change, and it is of no real harm, really, dpkg will never ask about keeping the old version or installing the new one. Please note that /etc/timezone is very similar to this, it is a conffile, it should probably not be a conffile according to policy, but being a conffile is harmless. Therefore I'm in doubt about the right thing to do. I'm willing to stop making it a conffile and creating it on the fly if it does not exist, but I would not like to hear any complaint like /etc/adjtime is not listed anywhere, it should perhaps be an `extrafile', since we don't have extrafiles yet, it would be nice to have it as a conffile. So: Should I make /etc/adjtime not a conffile? Should /etc/timezone not be a conffile, also? Thanks. -- 4c1c8d291ee452495ab491dc9833f580 (a truly random sig)
Re: Maybe it's time to split debian-devel-changes
On 20 Aug 1998, Martin Mitchell wrote: Santiago Vila [EMAIL PROTECTED] writes: Therefore, I will send the last proposal: http://www.debian.org/Lists-Archives/debian-policy-9808/msg00115.html to [EMAIL PROTECTED], so that whenever the new upload procedure is implemented, the list is splitted in the proposed way at that time. I suggest one change to this. Instead of renaming debian-devel-changes to debian-devel-changes-i386, it should be changed to debian-devel-changes-source. This way people who upload source packages for other architectures will get noticed, and the packages will be recompiled by i386 users. I expect that more package maintainers will be using non-i386 in future, and this should help the i386 packages stay up to date. I don't fully understand your suggestion. My proposal had already two different lists, debian-devel-changes-i386 and debian-devel-changes-source: * People subscribed to the first one are only interested in binary .deb packages for the i386 architecture, not in new source packages. Most of the Debian users currently subscribed to debian-devel-changes will want to stay here. * People who want to compile packages for other architectures different than the one the package maintainer provides (which may or may not be i386) should subscribe to debian-devel-changes-source. I think we should not force normal i386 users to receive source announcements not containing any i386 .deb binary. Thanks. -- e4044e0d5984450d58247be51446a5e7 (a truly random sig)
Re: Maybe it's time to split debian-devel-changes
On 20 Aug 1998, Martin Mitchell wrote: I suggest that the current debian-devel-changes be your debian-devel-changes-source list, because I think most of the people currently subscribed to debian-devel-changes are developers, more interested in new releases (ie source packages) than binaries. Ah, I now understand what you meant, but now I do not fully agree :-) It may be true that most of the people currently in debian-devel-changes are developers, but they are also advanced users, and most of them of the i386 architecture (this is a fact, not an i386-centrism), and I think that most of them are interested in new .deb packages and only a minority of them are interested in new source packages. Maybe the right thing to do here, since none of the new lists did exist previously, and since debian-devel-changes will disappear as such, is to let people to subscribe to whatever list they like and not to subscribe anybody automatically to any of the new lists. Of course, this would have to be clearly advertised, etc. etc. Opinions? -- f66efa4c339fa6826fa5d693d8dbf87c (a truly random sig)
Re: Maybe it's time to split debian-devel-changes
On 20 Aug 1998, Manoj Srivastava wrote: Hi, Santiago == Santiago Vila [EMAIL PROTECTED] writes: Santiago Maybe the right thing to do here, since none of the new Santiago lists did exist previously, and since debian-devel-changes Santiago will disappear as such, is to let people to subscribe to Santiago whatever list they like and not to subscribe anybody Santiago automatically to any of the new lists. Of course, this Santiago would have to be clearly advertised, etc. etc. Works for me. Ok, in such case, I think I will remove the debian-devel-changes becoming debian-devel-changes-i386 part from the proposal and will include the text quoted by Manoj as a final suggestion about what to do with the old list. -- 10213eb7afde97e72395598e07b7eb67 (a truly random sig)
Re: Maybe it's time to split debian-devel-changes
On Wed, 19 Aug 1998, Wichert Akkerman wrote: Previously Santiago Vila wrote: If I don't hear any serious objection, I will send the proposal to [EMAIL PROTECTED], [.. snip snip ..] Could you first take a look at all comments made and post a new proposal? If I remember correctly some nice suggestions were made. The only suggestion that was not incorporated into my second proposal was your comment about using personalized messages as freshmeat does. Unless you explain to Joey how to implement that in smartlist, I'm afraid I will be unable to incorporate that into a new proposal. Thanks. -- 62f8b4573264b5129a569db4881645a0 (a truly random sig)
Re: Maybe it's time to split debian-devel-changes
Splitting of debian-devel-changes = I'm going to summarize everything so far: * The list may be filtered in many several ways, but this does not solve the problem of bandwidth for people using POP (the too late problem). Therefore, most people seem to agree that the lists should be splitted sooner or later. * We don't want to split the list in a i386-centric way. Also, we don't want to force normal people (non-developers) to subscribe to more than one list. * The current list has not a *huge* amount of traffic yet (i.e. like debian-user), so we can wait for the new upload procedure to be implemented before we split the list. * There has not been any other proposal or suggestion of change after the last one. Of course, this does not mean that the last proposal is perfect, but I assume that in absence of serious objections, it may be considered good enough for our purposes. This second proposal takes in account the suggestions by Dan Jacobowitz and solves the i386-centric approach of the first one. Therefore, I will send the last proposal: http://www.debian.org/Lists-Archives/debian-policy-9808/msg00115.html to [EMAIL PROTECTED], so that whenever the new upload procedure is implemented, the list is splitted in the proposed way at that time. Thanks everybody. -- f418fa82df310ecdaf3800dfe0363b4d (a truly random sig)
Re: Maybe it's time to split debian-devel-changes
Hi. Seven days ago, I posted my second proposal for the splitting of debian-devel-changes. If I don't hear any serious objection, I will send the proposal to [EMAIL PROTECTED], where is the bug which asked for the new upload procedure, so that whenever the new upload procedure is implemented, we will not have to discuss again about how the splitting of debian-devel-changes should be done (this was my initial intent). Thanks. -- 6fc207a15afd38aa620fdff1884c46be (a truly random sig)
Re: Distribution of license documents (fwd)
On 17 Aug 1998, Manoj Srivastava wrote: The GPL, LGPL, BSD, and Artistic licenses do not apply to any software specifically, and can be considered stand alone. (If I am wrong, please point out wording in the license that specifies which package or specific software the license applies to). Do you mean something like this?: 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. Certainly, the GPL in base-files applies to all of the GPLed software in the Debian distribution. We would have just to agree on the definition of the term stand-alone. -- 185b228cb313ba9fb73823e9c52eeff9 (a truly random sig)
Re: Why licenses *are* free (was: Re: Why I don't share Manojs fears.
On 16 Aug 1998, Manoj Srivastava wrote: Marcus Brinkmann [EMAIL PROTECTED] writes: We ship software with a copyright attached to it. On the contrary. Look at what ships /usr/doc/copyright/GPL. The package base-files ships the licenses un attached to software. [...] Yes, but we ship both base-files and the GPLed packages in main. Maybe we need to discuss the meaning of attached? (Remember the KDE discussion?) -- 7db96708263cfd73e1e0746f3540a9e0 (a truly random sig)
Re: What RMS says about standards (was: [rms@gnu.org: Re: Questions regarding free documentation.]
On 16 Aug 1998, Manoj Srivastava wrote: Shipping the GPL as part of the package is the exception rather than the rule. and /usr/doc/copyright/GPL is a shipped standalone. Shipping the GPL as part of the *source* package is the rule. Since we have lots of GPLed packages it would be silly to have 1500 copies of COPYING in the *binary* packages. -- 242a709ab2c81eaf62a12258fbf25f65 (a truly random sig)
Re: Maybe it's time to split debian-devel-changes
-BEGIN PGP SIGNED MESSAGE- Ok, second proposal: The distributed, non i386-centric one: The debian-devel-changes is renamed to debian-devel-changes-i386, and an announcement is sent explaining the goal of the new list. There would be the following lists: a) debian-devel-changes-arch for every arch. b) debian-devel-changes-source. And the announcement policy would be: * Every time an upload includes any package which may be used by arch, it should be announced in debian-devel-changes-arch. This includes arch-independent uploads, i.e. every time the dinstall program installs a file *or a symlink* in the binary-arch directory, there is an announcement for it. * Every time an upload contains source of any kind, it should be announced in debian-devel-changes-source also, i.e. every time the dinstall program installs a new file in any of the source directories, there is an announcement for it. Benefits: * Users of the arch architecture would have to subscribe *only* to the debian-devel-changes-arch list (convenience for the users as a primary goal). * Although a binary-all upload would be announced in seven lists, this is not a waste of bandwidth, because subscribers of the different debian-devel-changes-arch lists would normally not overlap. * Developers looking for new source packages would have to be subscribed to just one list also, debian-devel-changes-source. * Most source i386 uploads would go both to the debian-devel-changes-i386 list and to the debian-devel-changes-source list. This, again, is not such a waste of bandwidth, considering that the number of subscribers of debian-devel-changes-source would be really low. Please, accompany your objections with a more better proposal :-) -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNc7VeiqK7IlOjMLFAQFnQwP/fmjK6L1PutXOv70EG5+y5tsAP4k/W8Ee bFJIgL+M1ZTr7anOA6KB2VqJO7xTAfxMCwuK45Id+C7vrZEUX8606yU39nfcYMgZ ujTsbFDJp4N3Caf/QESFPcS3UFFHLLd7yuuU4cKP+kUMY4iDZjMQoVHaan8Kr3iW mldb0+cPr5w= =8WPG -END PGP SIGNATURE-
Re: dpkg support for internationalized/localized programs
-BEGIN PGP SIGNED MESSAGE- On 29 Jul 1998 [EMAIL PROTECTED] wrote: [...] Then we can localize an internationalized package. For many languages And everybody agrees that there is no reason to keep in one package all localized versions. I disagree. The FSF also disagrees. All GNU packages keep in the same package all localized message files (.gmo files) and we do not plan to splitting them yet. What you want is better achieved by making dpkg more clever, i.e. ideally dpkg should have the ability to exclude certain directories when installing packages. If we follow your suggestion of making a different package for every language, then Debian will end up having not 1500 packages but 1500 x number-of-languages-it-is-translated-to. This is not very practical. On the other side, I think the boot floppies should switch to gettext as soon as possible, so that translators may use all the gettext tools (msgmerge, for example) to manage the translated files. Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNb89liqK7IlOjMLFAQE8RAP9EJSLwnlY0eVHC06FiOdEOOPPFMuROwfH H/+PErm35hcsqU2rUrfnQ4fpQzCdjnzmG2z1dHfBJEr1Zqj+sDeovkIJB7DmfMQZ wTF/sSy+cVv9YRIBsEWU4kSAXBNrV17yQE6yBO1DSxR7j80uu/6Ff3EPw8iaWQVq +gsYjygZEnw= =6zOr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compressing *.db files in /usr/doc
-BEGIN PGP SIGNED MESSAGE- Marco Budde: SV I have received a suggestion for debstd, namely, to not compress SV any *.db files found in /usr/doc/package by default. No, I've suggested to compress only know file types instead of compressing everything. Yes, and I think that the suggestion of compressing only known file types is worse, so I'm asking here just whether compressing *.db files is ok or not. Please, bear in mind that since debstd is in maintenance-mode-only, I'm not going to change it in a very incompatible way from night to day. debstd compresses a lot of file types found in HTML documentation and this is really bad. That's exactly the reason why *.jpg files are not compressed, for example. What I want is to be sure that not compressing *.db files is the right thing to do, and whether or not debhelper should do the same. Raul Miller: [...] I think the appropriate thing for debstd to do is allow a way to uncompress files (or whatever else) after they've been compressed. Well, remember that since debstd generates the md5sums, it has to be the last command that does something in the debian/tmp tree (save chmod or chown, of course). debstd has the option -c, which leaves compression to be done by the user before the debstd call. Is this enough? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNa3xWCqK7IlOjMLFAQFehAP+J0jbLo48Lmqa4T/U6g0cf229wm1Ymgui +JELIgoQW6sLAkzhG0lk6LO6k0QMMdo77/PGW163d3fiuo3zKy2owwut8BlnCTfk MgQx2y4PAodqFue3bqRuCxs0txvHMUxn6splpvkdV3D2YjF4G+G/fEjJvF4ZHZvf 19jiEP4P3S0= =O5FQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Compressing *.db files in /usr/doc
-BEGIN PGP SIGNED MESSAGE- Hi. I have received a suggestion for debstd, namely, to not compress any *.db files found in /usr/doc/package by default. I'm in doubt about this change. Is not compressing *.db files in /usr/doc/package reasonable as default behaviour? Would debhelper maintainer do the same in debhelper? Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNatCxCqK7IlOjMLFAQFB+gQAp55cEHkuugt+mszfudyhru1fPBFF/9Wi XElCgkxO9vSYICaKocJn7oGCLNJRN1QKDkk+m5mLcKfVR2FAISv16TvCXtAq+VjT q5FhTGGuva3lseb5P71KRGzK8EZ1A7xySFro/XwWDFz2qfcsSSGwq0bvZlRVJE0r qt/9pml9660= =CG4e -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Provides: emacsen ?
-BEGIN PGP SIGNED MESSAGE- Rob Tillotson wrote: [...] Since this emacs does not follow the new packaging conventions for emacsen, it is incorrect for new-emacsen packages to depend on emacs as that will cause the installation to break. (Which is exactly what the packaging system is supposed to prevent.) Oh, I was told that when you upgrade, you are supposed to upgrade everything, and therefore it does not matter if, for example, installing libc6 in a bo system breaks the old emacs completely. Would not have been easier to keep the name emacs for emacs19, but allowing other packages also to provide emacs? This way dselect would upgrade emacs to the version in hamm, which in turn depends on emacsen-common, and everything would work. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNX+x2yqK7IlOjMLFAQHhZQP7B8nf9DAmkVYhCPS26RfAC5z422iMGxD8 aGI3kU2duAUEv1xtKhCirxcptFc4ejGm3jbQgQNPsJ+oBbwo6yY03UxeoE+SFc/7 37cAGjAzRocv+SL/iyhMB7Z07yq7rWO9BwYEfN5Mf88WvJSEjMDEK0S64Z0d38it vrzwSPE1h8s= =8i03 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Provides: emacsen ?
-BEGIN PGP SIGNED MESSAGE- On 11 Jun 1998, Rob Tillotson wrote: Would not have been easier to keep the name emacs for emacs19, but allowing other packages also to provide emacs? No, because the old emacs doesn't provide the same capabilities as what is now called emacsen, The old emacs does not provide *any* capability in a libc6 system. It just core dumps ;-) So this could have been a good argument to keep the name untouched (i.e. emacs == emacs19). -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNX/LfCqK7IlOjMLFAQFJGgQAiOOo1gU3sDliFpEOnMphyU00XMsgI10b aH04D8aCwaVgO9erVgNv2uyyC2pNJ8Cnx2/vDjmTkGTPiEsZCgsOTsITM1NJvYEk 17udu4roJ0hUYyBvAozKBL+hYe3dvqJ1Z5zHUuvfycp3UDNPK3P3UbrySU385gym 8qXeXJEuODQ= =erB8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conffiles versus configuration files
-BEGIN PGP SIGNED MESSAGE- On 31 May 1998, Karl M. Hegbloom wrote: Santiago == Santiago Vila [EMAIL PROTECTED] writes: Santiago Mmm, do you mean, for example, that /etc/init.d/* Santiago scripts are not configuration files, because they are Santiago actually scripts (i.e. programs, not files that contain Santiago data)? Santiago [ Please, note that I'm not objecting being them Santiago conffiles ]. I think many of them *should* be in the conffiles list. Please, note that this is already policy [ I do not propose to change the policy in this ]. However, I am still a little bit confused by the fact that people still call them configuration files. Is any sh-script a configuration file for the /bin/sh program? Well, perhaps this is just a semantic issue that does not worth to be discussed, really. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNXJkuSqK7IlOjMLFAQF6yAQAlNO02c3kRb4hxRmEpNNBQDVZiKYDnJ3Y UyHxiWFLgRd9g60dl54XxNAPo+5NFTJ2NDH3zuS6+8Xy2vkmMo2urfbJPds0X5/e lumFUeAIwwjVhHnRdV4Qcnopfl4dxBhgF7EjbDmP7+F/xSi4uCPf/aA12ELSX7Vd MbZ8A152JVA= =Pkc7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conffiles versus configuration files
-BEGIN PGP SIGNED MESSAGE- On 31 May 1998, Karl M. Hegbloom wrote: Kai /var/list/.bin/mimencap.local /var/list/.etc/archive.txt Kai /var/list/.etc/help.txt /var/list/.etc/rc.archive Kai /var/list/.etc/rc.custom /var/list/.etc/rc.main Kai /var/list/.etc/rc.post /var/list/.etc/rc.request Kai /var/list/.etc/rc.submit /var/list/.etc/subscribe.txt Kai /var/list/.etc/unsubscribe.txt Manoj What on earth are these files? If they are user Manoj configurable, how come they are in hidden directories? Why Manoj are they not in a subdir of /etc, with a symlink as needed? Manoj This seems like a bug to me. Those are for `smartlist'. They are `procmailrc' files. I like them where they are, since they can be backed up as a set, separate from /etc/. They should be probably in /etc, to be FHS-compliant. This is already reported as a bug (Bug #10044: smartlist does not follow FHS yet). However, there is no procedure in dpkg to make it to compare md5sums from /var/list/.etc in an old package with the md5sums of a new package having the conffiles in /etc/smartlist. This means that making a smartlist package which is *both* FHS compliant and compatible with the previous release is going to be a little bit tricky, because just copying configuration files in the preinst would be sub-optimal. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNXJnHiqK7IlOjMLFAQGdGwP/Rc4lPfudftLUs/WockvwR/Rrc3pPY437 LzY6o4HnOzsTPZt02gEPZ3st32WnbIqaisdWOU9bTauIpvbLepYi+ymLR0XXIcOK rjQyTKLFBfCjGG37XVNQc4Ntpvg50LEjNhLjF6uUK4fAbgnpv+O7FJYmDUbggL3M tXCdldz3nVc= =cQG3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#21969: debian-policy: needs clarification about Standards-Version
-BEGIN PGP SIGNED MESSAGE- On 2 May 1998, Manoj Srivastava wrote: Packages only have to specify the first three digits of the version number in the `Standards-Version' field of their source packages. only three is three. I fully agree with Martin in that if 'at least 3' was intended, it would undoubtedly have been specified. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNUyEBSqK7IlOjMLFAQHGiQP+Jdu4ZpyVqMf4YIMoDXlyFo/RXBYowahy pVBzvW6nSOeUTtJSLCDsS70JTqR3n5FkR2ah+saPiHIRXFZLYR4mT0K6Qne6ghc7 9v8CygZ7SI0YKUXVMrwTDYZDgPBYpwzWRgx3tB+CS5vDqAX/nkgQSp0GEZ4OLFIe O4EKvlkKrvE= =Qtoa -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conffiles versus configuration files
-BEGIN PGP SIGNED MESSAGE- On Wed, 15 Apr 1998, Ian Jackson wrote: I mean that just because X is a conffile doesn't necessarily imply that X is a configuration file, or vice versa. Could you please tell us some examples of conffiles not being configuration files, just to make it clearer? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNTYwbiqK7IlOjMLFAQEN5AP+Kx/mzDI1/+2oxW5LxlLFmDsMeo4PmrYE mZbsvTnq1Q5YjkUKfbMujMfGtY3UiuP1EzyVlh2ypq5xP1zPAoiFpGeqU5Efu6k2 Jyh9V36XZbH9yHhioXZ4WtYuFR0dcEJKKQyOtMPAq+CFGpM5nQCwBanlpq9cm8tv MauNaDPttTc= =9/m+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug#17532: query of policy: what kind of bug is this?
-BEGIN PGP SIGNED MESSAGE- On Mon, 13 Apr 1998 [EMAIL PROTECTED] wrote: Could all of you reading this review bug #17532? Question: what severity should it actually be? In the bug report, you said: this bug has prevented ALL logins (possibly including single-user/maintaince mode; DEFINITELY including root) to a fairly recent hamm box If this is true, I think it should be important or higher. Since it is an essential package, it does not matter if it is important, grave, or critical, since we will have to fix it anyway... -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNTILpSqK7IlOjMLFAQG/pwP/bP104rGFveUtVllOPMzyViGP83O4LhhJ zty7TEEt+Fy00YfpYXjAXzqP6OdBEQ/sD2q7O7Iht78jJ/ufySrIvn68gCONV2tS qGFbjpjd0r4/KqpNdqZqqfmL5CJ61JOkecvLEayYx6wusUCLwTLLzh4OraGTHuDE 3Aqu2cVNDd8= =Np/P -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: General bug policy
-BEGIN PGP SIGNED MESSAGE- On Tue, 7 Apr 1998, Ian Jackson wrote: I also propose the following guidelines for determining whether a bug report should be kept open, etc. These may be stated elsewhere already, but should be consolidated: [snipped] I mostly agree. Could we please make this policy right now and fine-tune it later? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNS40zyqK7IlOjMLFAQE3bgP/Sg5IOTTL23bjOs4XhN0Ozcg6Z166vtQl INkqRXxkMM1C+/97vPJM9b4roHhmYSd8UdlB+/CROFUUIB72Ez8uLd16aFcXGoBc DQbs4a+tohJhr/N1Z6fQ5CxROV6QeaVtyh3xdbm9nU9zHH8RHnEnN9bU++R1WcHT ljYXa0hwRo8= =OyNb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: General bug policy
-BEGIN PGP SIGNED MESSAGE- Manoj is right. Rewording: Are there any objections to the policy proposed by Ian? I would like to see approved (by the usual procedures) a policy with respect to bug reports as soon as possible, because we have no policy at all so far (only current practice). -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNS5akyqK7IlOjMLFAQGxUgQAoFJrumTD3KtqRbJjR2yH3cUuU5xmBRHl PNiMKwwkLVBo02idmsHLAJanD9XP8YE57RGAPiyk/Xf6DCD5Lv6H5YkINuxjFhXg XI+nGOBRj/SNG+lxtVI2oqxDV+UzXsJktteWNhSGlUn+pz2S/YfAgQfbx9kyQP48 Sfk3eVEdgRQ= =9Mnb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: General bug policy
-BEGIN PGP SIGNED MESSAGE- Manoj Srivastava wrote: In the specific dispute you are involved in, the letter of this proposed policy has already been followed. In short, I would summarize my old bug as follows: 1) A .m file in the future (or a computer in the past) causes octave to reload it. [ Everything right so far ]. 2) The current kpathsea library makes the reloading very slow, and this is planned to be fixed, according to the PROJECTS file. My bug report was 1)+2), but the maintainer insisted in closing it by saying it was just 1). In the specific dispute I'm involved, I have reported 2) now as a separate bug, and now the maintainer calls me stubborn and says that not even 2) is a bug. I hope you will agree with me that this is good reason for me to want *some* policy about bug reports to be approved soon. But I have to agree with you in that normal procedures should not be bypassed. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNS5dpiqK7IlOjMLFAQE5WQQAgtbHyyEe+CvmrtE9IRrMGxrSk4A1z+PM 8y3sbXDKyYBdsuMzTx5scFQDEYPEHEy7Wi0iNl9x+RqhjGrUTxOcan586iTZF0u1 MXvpfF5jUl70hgRrYGmKHynRXZ2e3XnTUQNjfMnrJ9JLuWvEAggY+QkF1CmbvEtO dKSlr+YvJLo= =kSmy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When a bug is a bug?
-BEGIN PGP SIGNED MESSAGE- On Tue, 7 Apr 1998, Ian Jackson wrote: 1. Santiago initially mailed [EMAIL PROTECTED] about this matter, and didn't go away when Guy told him to. He did when I referred him here. (At this point neither Guy nor I entered into the details of the situation, after having determined that it was nothing to do with us as bug database admins). I mailed [EMAIL PROTECTED] because I received this from you, through the bug tracking system: Their explanation is attached below. If this explanation is unsatisfactory and you haven't received a better one in a separate message then please contact the developer directly, or email [EMAIL PROTECTED] or me. The explanation was unsatisfactory, and I didn't receive a better one in a separate message. I was not going to contact the developer directly, because he was clearly refusing to relate the timestamp problem with the kpathsea searching algorithm. At this point I don't have clear whether the words or me in email [EMAIL PROTECTED] or me are still valid or not. Are they valid? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNSs8EyqK7IlOjMLFAQFpUQQAljBdajlFEH1QTRNeNperljtVu8mN4YCY MIXXrRFSbcJ/+S1hUjIqWLI3Yu2WndT+bPJxE6qhEFHjexlikhDY0UbNN17u6WB3 YhgnVLhVzW/6oI1F9m9o5AdC5rzchyleKz9A2f13YQ8FIdWXyspGwm2Q3uT9a9+j Kcrw9w3rluM= =NuGo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When a bug is a bug?
-BEGIN PGP SIGNED MESSAGE- On Wed, 8 Apr 1998, Ian Jackson wrote: I hadn't realised that developers wouldn't know that there would be a better way for them to sort this kind of thing out. Do I need to add some text saying `If you are a Debian developer, please use our internal procedures for resolving disagreements over bug reports.' ? No need, if you add that phrase somewhere in the documentation of those internal procedures and it becomes part of the bug system documentation (in addition to the simple rules you proposed yesterday and with which I mostly agree). Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNSu4/SqK7IlOjMLFAQHhSAP9GcgOfzyY06af+ruO6J+qDhUv9t+yvl1I jpLJmwuO6+nyvtc0oBQ8iCqw9zQ7qkK7ajH2IOlDncY41qFz+A/ZySDdCEVrqytb 9krlDoTsgZnCa5rgOQBDxICBhhB3QP9q+NuBkGoRmklnUU1ETgQjwI2uu0l/aHjO eKSCPx6JMqA= =Z5yQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conffiles versus configuration files
-BEGIN PGP SIGNED MESSAGE- On Wed, 8 Apr 1998, Ian Jackson wrote: `X is a conffile' =/= `X is a configuration file' Mmm, do you mean, for example, that /etc/init.d/* scripts are not configuration files, because they are actually scripts (i.e. programs, not files that contain data)? [ Please, note that I'm not objecting being them conffiles ]. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNSu6OiqK7IlOjMLFAQG+0AP/T/mmHyRQh/muwyrPAOpQpVKrHZSV4Aee p/e2WeeLNn+ndddZawD0l7g7jOGcRxHAhuGWFveMapWh2u31QSGMNrRhGSK1L2yH 0pTdTS7UMwzmgY/UX2Iv6i2ADi/Nag242v6J1ZFL4QRJscyD2MwBx3BsE/pspc8s CfF0xzJxnEY= =6k/P -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
When a bug is a bug?
-BEGIN PGP SIGNED MESSAGE- I have a great difficulty in convincing the Debian octave maintainer that Bug #20561 is a bug. I have explained him in great detail why it is a bug but he still says it is not and even *refuses* to discuss about it. May I also close all my bugs by saying they are not bugs? I think we need *urgently* some clear guidelines for managing bugs. Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNSoiACqK7IlOjMLFAQE99gQAsB94zVvJ8VsMO84+jR0f2hWXf2TJEUk1 UzEJ5Omo+J1JJ5OzXnHjZr5P1Zc2UjydbDSWnPKqZfOwfi+iN6A5Sod2UgusHiTZ A95+t2Vq7S3eInX83rOVGDiDf6b+Gt+91nJ17F99+ENzvnoHI5ubHpn9ckrznCka FLjmECT4sIo= =ScvZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When a bug is a bug?
-BEGIN PGP SIGNED MESSAGE- On Tue, 7 Apr 1998, Ian Jackson wrote: 2. There are two issues being confused here. One is the behaviour of with respect to files in the future, and the other is the search path ordering. There should be two bug reports. Dirk also thinks I'm confusing two issues, but they are in fact related. If the search path were the intended one, then I would not have noticed a slowdown when using files in the future, because octave would find the f.m file in the current directory immediately. If there were two bug reports, I would agree that the first one could be closed. But since the first problem would not happen if the second is fixed, I don't think it is worth to report it again in a separate bug. We have the retitle command. 3. We generally have a rule that says package maintainers get to make decisions about their packages. This is not universally applied, and is not yet formal - for example, certain bugs have been left open as wishlist items against the wishes of maintainers. Yes I know at least one example of that (#3253 ;-) It would be worth to clearly state when a wishlist item have to be left open against the wishes of maintainers. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNSqHIiqK7IlOjMLFAQG+qAQAtiV8iOt4sh0EqaUgu1MZ4wTMi86VGjhE ORuk8mGSbQWsc4AT9GP7rFqmJFeltKpjR0JcBOzHVlE4qd72p/c+2TOtaGFDTV+L QzgkJWo1hd0dbnyGVmT9nHcBldFj2h+o3WZw5et6cXl7q1+2HJnAofnZdAVLVe1Y v4H+e5T/Eqg= =/2cs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: General bug policy
-BEGIN PGP SIGNED MESSAGE- On Tue, 7 Apr 1998, Ian Jackson wrote: 4. Noone but the maintainer of a package (or someone acting on their request) should close its bug reports. We could be flexible here, in some cases: For example, if someone submits a bug, and just after sending the message he founds that it is not in fact a bug but a feature, then the submitter (especially if it is also a Debian developer) could be allowed to close his own bug, if only to make life easier to the maintainer. [ After the bug is closed, the maintainer may of course disagree, in which case he may reopen it and change the originator to himself ]. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNSqMNyqK7IlOjMLFAQG+DAP/dKhKqsAepwf0rFyf+XmdPRSH3Uzz0s0D ZwMwUWkp6+3iMSsSb1zNaNYrDdwqwudqMfmIgsnAauVR2XuprcQR+6YxVfzqayKn O3Xi8XeZJFAWVDvNI/viONLm4lI98pqiHAq1HpSkWnCar4k2KHfkfI17cGVE2zNH Y2IO8Ov4QGg= =uN4e -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conffiles and Configuration files (again)
-BEGIN PGP SIGNED MESSAGE- On Tue, 7 Apr 1998, Anthony Towns wrote: What I'd like to propose, therefore, is extending the conffile label to cover all configuration files. Why do you want to do that? Why should I want to be asked each time I upgrade the system because of local files like /etc/init.d/networks, /etc/timezone, /etc/papersize or /etc/gpm.conf, to name a few? This would, as well as providing a list of just about everything in /etc, eliminate any remaining confusion about what the difference between a conffile and a configuration file is. Confusion? What confusion? :-) A configuration file is a conffile when the package maintainer decided to let dpkg to handle it via the conffile mechanism. Is there anything wrong with the above definition? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNSjxbiqK7IlOjMLFAQEcEQP/fESM1PVdUjOpyIDbC+HbG58TU7GybJ0p tooEyOX9SdFbCykzs3iBvG3KtkNjpa8iZDk8VQr9f6sI+haKbyFebGg+HWfCdYuP HbWPxK+Bhd3W0dSXNhjHCQx3oQIygSGLxeSYxpY+9QU1wAX/JCJathG4ICW9FTPh 0lmsM7ZyUhk= =GNf6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: need input: essential packages and pre-depends
-BEGIN PGP SIGNED MESSAGE- Well, if /bin/ps is not essential to the system, why it is in /bin? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNRgQfiqK7IlOjMLFAQFMlQP/eSQNds3w/1JjznI/YWEq8vRJgBcljPtX UVE+L2oNiWRrLRi8eDQ6mJ+7naqVBr7sMpeNvRXujEik9WgVoCfHc/yopUjJ6bVi 7me0K0aAv0WQ4ty4MU4b9VaKTib2a0tIlmf82UK6PTnvLJeYAOT9uzcD0o7jAdrM yC3hEXPVq+8= =Fth6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: need input: essential packages and pre-depends
-BEGIN PGP SIGNED MESSAGE- Fine. Summary: Either 1) procps is(should be) essential. or 2) procps is not(should not be) essential. If 1), I would propose to add Pre-Depends fields for libc6. If 2), then someone should report a bug against netbase for using ps in the postinst without having a Depends: procps. The same for postgresql. Are there any more packages like this? (I think we should minimize essential packages). I agree, but they are already quite minimized... [ I'm still a little bit confused by the fact of ps being in /bin/ps and not considering essential the package that contains it ]. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNRgYxyqK7IlOjMLFAQHgrwQAseWPdnZijclSo5oW/Ks27ws0BWIJ+4M5 stPcA+IXysABeQuVM5BqOGY9Ge060RDOxGkE55FenN/9WiRBOEiQ+80fL2J+EN17 OoxEtPsmBJSThVfpLoTtsuUHJDX7fRmteGg4agh2Ig/0AfEwHYyb/KIrYySC5m0n cdhc2EPavnE= =PR6t -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: need input: essential packages and pre-depends
-BEGIN PGP SIGNED MESSAGE- On Mon, 23 Mar 1998, Ian Jackson wrote: 3. ncurses-bin contains clear and reset, among others. If this package is essential, then those commands are allowed to be used in maintainer scripts. I think I disagree with `if this package ... scripts'. It may not be explicitly stated anywhere, but I think it's reasonable for a package to contain both really-essential bits and others. I agree. I talked about clear and reset because I thought they were the ones it made the package to be essential. The complete list is: captoinfo, clear, infocmp, reset, tic, toe, tput, tset I think that no package should (or indeed does) use `clear' or `reset' in its preinst or without using a dependency. Do you mean ncurses-bin should not be essential? If it is not essential, the user will be able to remove it. Is really useful the freedom of being able to remove ncurses-bin without using - --force-remove-essential? I will postpone any bug[*] on ncurses-bin until we all agree on this. [*] Either add Pre-Depends or drop the essential flag. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNRab7iqK7IlOjMLFAQGH1AP/ZOS5sk10JhDLnVE+sboSyXmNaO/0mpN/ v2CIBDy9SQXDoholNsZ5wy44iLK7Qr/AAuzAMvIlvX/Q/vnRDsqTD3v2XcovvBCr vj+cnYIHRXZlUzJYhfb50lxbPzmoY13CBTNzwRGnoaGuycive3pUO2zWEzogXCnr JWpVKTuA4kg= =WkTm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: need input: essential packages and pre-depends
-BEGIN PGP SIGNED MESSAGE- On 23 Mar 1998, James Troup wrote: I can't see any reason for ncurses-bin to be essential. Well, I can see a reason: if the console is so messed up that you don't even see dpkg when you write it, and you have not clear or reset, then you have a problem. (Yes, you may telnet from outside, but remember, not all machines have a net connection). What do others think about this? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNRagayqK7IlOjMLFAQEPsgP+KzKS6UcKBAKerSoY9SdrzslsU5U+Kz94 L8inyizgtMidKI50OOLtGgJ7RnYM8uCAPJZXMV1rkY7r4+B7UkWIUDz6oEicEtc/ lQVxa7/NgR8hbPfnHPOc+yvuwS4QetWaPcQxuCSSwrGiNiKiNx3yZ6D4IwSe8N+J SmKghu6FuQg= =CYLn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: need input: essential packages and pre-depends
-BEGIN PGP SIGNED MESSAGE- James Troup writes: Santiago Vila [EMAIL PROTECTED] writes: I can't see any reason for ncurses-bin to be essential. Well, I can see a reason: if the console is so messed up that you don't even see dpkg when you write it, and you have not clear or reset, then you have a problem. That's not enough reason to make a package Essential, the policy manual clearly states that removing a required package can leave your system totally FUBAR, [...] ... in which case it should be probably essential also. The paragraph you quoted talks about required packages, both essential and non-essential, so, frankly, I have no idea why you quoted it. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNRaq+CqK7IlOjMLFAQGmswP/QRoCKpZ0CPh7CmK59hnUlrpmPTIFnBAq da1ggn10igOo29WUqY4Ijp6+mKCCqWK2RWrUrH8IGMgTwqfAIB0LQbl5pJlyZ0HR qjYc/r/+lyRVuMTGnlKoO6HzcRsArw1epQIPoRpsxse9biES47Gd1MD5HTSZ23WD t5u8ZbH7KBw= =NinW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: need input: essential packages and pre-depends
-BEGIN PGP SIGNED MESSAGE- On 23 Mar 1998, James Troup wrote: Santiago Vila [EMAIL PROTECTED] writes: That's not enough reason to make a package Essential, the policy manual clearly states that removing a required package can leave your system totally FUBAR, [...] ... in which case it should be probably essential also. No. That's not what is [it?] says. Well, the paragraph you quoted does not say that. But please, tell me an example of required package whose removal can leave your system totally FUBAR but it is not essential. I will submit a bug immediately if there is such package. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNRavbiqK7IlOjMLFAQH+ggP/WUUjQgSeQ07WF5CC9HAL4gTOeHf2mJVq bdCD0JeXo1mKuqXuf9kpWqoM259pQfygoQpNRZROgofbi//2jnp00N2sq+tBHi9F 63KItuAI43d/blpKefOLaP3nGoSbU3+v82boWhae8J36tnw411QeQwQ7MWx2E7gM Gn74/5eztz0= =UNhv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal how to handle mass bug reports
-BEGIN PGP SIGNED MESSAGE- On Fri, 20 Mar 1998, Ian Jackson wrote: Santiago Vila writes (Re: Proposal how to handle mass bug reports): ... Mmm, well, what if I sent just one bug against ftp.debian.org saying these 100 packages should not have `optional' priority but `extra'? I would say your proposed policy is incomplete. I would add the following paragraph: Bugs against ftp.debian.org count for as many bugs as the packages it refers to. Therefore nobody should submit bug reports against ftp.debian.org if such report refers to five packages or more I disagree. The problem with many bug reports isn't that they request a lot of action, but that they require a lot of action to get rid of. Mmm, requiring a lot of action for a lot of packages has not to be discussed also? This is also a problem, not only getting rid of the bug themselves, because people may disagree very easily. I don't think submitting a lot of bugs or submitting a bug affecting a lot of packages are so different things. I thought we were trying to Discuss first, submit bugs later. This should be valid for your bug also. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNRJxcSqK7IlOjMLFAQGLSgP/UF2s2Oq9WBvwAne/xkY42V4si7zn48IA cL+kMhdA4tTzDHClMb7j0XqNOrJ2XNE6SuegHajJsxlcCN/Io6t8nPmTFauQ+3TG xV2JYiicRDjNrDBRX/3pflRipltbVmOnQRvKU+yaujfwcMEZy+xG2Vq6eWVFhhw8 MyCcobg93Xk= =Kgfq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: need input: essential packages and pre-depends
-BEGIN PGP SIGNED MESSAGE- On Fri, 20 Mar 1998, Ian Jackson wrote: I'm sorry, what precise policy change is being proposed ? It is currently policy that Essential packages have to use Pre-Depends for things which they need to support the packaging system. They should use Depends, otherwise, just like any other package. The problem is that it is not clear enough what exactly is the packaging system. In my interpretation, all prerm, postrm, preinst and postinst are part of the packaging system. Since any prerm may use any ordinary program from an essential package, essential packages have always to work (this means using Pre-Dependencies for all libraries, at least). For example, if diff is essential, it should Pre-Depends on libc6, because otherwise maintainer scripts which use it would fail. Right? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNRJzOiqK7IlOjMLFAQEjkgP9FMRvV6Mcqyy3Qh0YVa4ckkiuhg5uX7lt p9Mvc86JPIo7LS/EZTFN7zv3m8q91N/L9gnBXaWEbrRb71LPm0cROQV5u5C6Vnol rngi1zQJO5TyO20Htsvo5TzZjWxg1DJn3pVThb0/Efdfi7oTZ/5ueHGTj3hDz/4j Fds6MkhPbsM= =fNT4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: need input: essential packages and pre-depends
-BEGIN PGP SIGNED MESSAGE- On Fri, 20 Mar 1998, Ian Jackson wrote: Santiago Vila writes (Re: need input: essential packages and pre-depends): ... For example, if diff is essential, it should Pre-Depends on libc6, because otherwise maintainer scripts which use it would fail. Right? Yes. But if diff3 uses a different library, that wouldn't need a Pre-Depends. (We should document what commands/features you may use from from an Essential package.) Ok, diff just depends on libc6, so in this case perhaps there would be nothing to document. Or perhaps in such case it would be wise to have diff3 in another separate package to avoid confusion (diff-nonessential). Instead of talking about theory, I think it will be better to be practical. Here is the (automatically generated) list of essential packages having (still) a Depends: line: 1 bsdutils Depends: libc6, sysvinit (= 2.59-2), shellutils (= 1.15-3) 2 base-passwdDepends: libc6 3 ncurses-binDepends: libc6, ncurses3.4 4 gzip Depends: debianutils (= 1.6) 5 base-files Depends: awk 6 e2fsprogs Depends: comerr2g, e2fslibsg, libc6, ss2g 7 sysvinit Depends: dpkg (= 1.4.0.21) 8 diff Depends: libc6 I will comment on each one: 1. bsdutils is essential because it contains /bin/kill. Therefore it should probably Pre-Depends: libc6, we don't want the kill command to stop working in the middle of an upgrade, do we? ** I will submit a bug against this if nobody objects. I don't know the reason for the other dependencies: sysvinit (= 2.59-2), shellutils (= 1.15-3) sysvinit changelog says nothing about 2.59, but shellutils 1.15-3 replaced bsdutils' chroot with the GNU version. Mmm, is really a Dependency what we need here? 2. I think it is ok that base-passwd does not Pre-Depends on libc6 if it does not run update-passwd in the postinst. 3. ncurses-bin contains clear and reset, among others. If this package is essential, then those commands are allowed to be used in maintainer scripts. So either we keep this package essential and put Pre-Depends: for both libc6 and ncurses3.4, or we downgrade it to just Required but not Essential, but in such case, someone should scan the entire set of maintainer scripts of all current packages to be sure that no program in this package is ever used without a Pre-Depends on ncurses-bin. I think this is a bad time to change the essential status of a package. ** I will submit a bug against this if nobody objects. 4. gzip Depends on debianutils becaue gzexe uses tempfile. So either we forbid the use of gzexe in maintainer scripts, or we make gzip to Pre-Depend on debianutils. I think it is ok to keep it as it is, but this should be documented somewhere (that gzexe should not be used). 5. base-files Depends on awk because we wanted to make awk essential. Since awk may be any of mawk or gawk, and they may be used in maintainer scripts, then both of them should have a Pre-Depends on libc6. ** I will submit a bug against mawk and gawk if nobody objects. 6. I reported this already, because e2fsprogs had already Pre-Depends fields in Debian 1.3.1 and they were lost in the split. This package is being rewritten, so there is nothing to comment on it. 7. sysvinit's changelog says: Depends on new dpkg for the new update-rc.d Well, if this is a simple Depends, then we can install sysvinit without upgrading dpkg, and dpkg would not even complain. Bad thing. Are we sure we want this? I don't think so. ** I will submit a bug against this package if nobody objects. 8. We allow diff to be used in maintainer scripts, right? If not, this should not be essential. If yes, we would need a Pre-Depends. I think this is not a good time to downgrade the essential flag of a package that has been always essential. Therefore if nobody objects, ** I will submit a bug against this package if nobody objects. I also think that some other packages would benefit from having a Pre-Depends, for example: do we want deliver or procmail (MDAs) to fail in the middle of an upgrade? Do we want a listserver to fail in the middle of an upgrade. Do we want a MTA to fail in the middle of an upgrade. Should not we make deliver, procmail, sendmail, smail, exim, smartlist, majordomo, etc. to Pre-Depend on libc6 also? [ Remember that we have told our users they do not need to put the machine in single user mode... ] -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNRKrEiqK7IlOjMLFAQEeJgQAnKuYVCeAwsSKdEaUaIMydQ16a5rkxr0g ZQlxA/etd8tRAoJwnaUH0ggLeiFNnKk6c/2AjEtLMBHbCqfyeDUvpV7mj6TjZmue KPOW2CxTGg9RR1ym42wNDnxbt5xkt/MU1pGzWAhp9jPj4T5fcyso/JIIPz1gj0AE RV/I3opzFXI= =Bglx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal how to handle mass bug reports
-BEGIN PGP SIGNED MESSAGE- On Wed, 18 Mar 1998, Ian Jackson wrote: Noone may submit many bug reports or send mail to many maintainers without prior approval for the specific person in question to send mail under those specific circumstances. Even for violation by packages of an already-established policy, no more than five manually-written and manually-sent bug reports may be submitted. Mmm, well, what if I sent just one bug against ftp.debian.org saying these 100 packages should not have `optional' priority but `extra'? I would say your proposed policy is incomplete. I would add the following paragraph: Bugs against ftp.debian.org count for as many bugs as the packages it refers to. Therefore nobody should submit bug reports against ftp.debian.org if such report refers to five packages or more If you agree, could you please close Bug#19920 and discuss guidelines about package priorities *first*? [ I have been flamed in the past because of filing bugs without asking first. ] Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNRFi7CqK7IlOjMLFAQHO5QQAjfevjrpFIU7YK0NxIdecCp+OVdXYzytO FQvUroHbBi3pnxbuhYe6EKlf39cpgr/DTK+ewcxMSSgE5R2gPvD+pUgw+awJ/iaf wBt++oBQzjvW8Ae3FzKgpk2gWmdhcZtI8nJLeYhCFdPaDD6i3KjurndnRyq0yx5x TwQ5jbxfrNs= =YXam -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libtool varying versions
-BEGIN PGP SIGNED MESSAGE- On Tue, 17 Mar 1998, Marcelo E. Magallon wrote: On 16 Mar 1998, Ben Gertzfield wrote: Do I remove the newer libtool from the upstream source and replace it with the current libtool in the Debian distribution? add libtoolize --force --copy to debian/rules. This would make your package source-depend on libtool. And automake maybe. Definitely autoconf. In the process Makefile.in - Makefile the m4 macros are expanded, and ./configure should be regenerated just to make sure the libtool m4 macros are not different from those used upstream. Well, it was agreed (more or less) that no Debian package should depend on automake, autoconf, or libtool (it is not needed), because no GNU package depends on any of these tools either (if GNU can do it, we can do it as well). I would suggest to add a rule libtoolize to your debian/rules files so that it will only have to be called by you *before* creating the package. This way, this special rule would not have to be called by people compiling the package for m68k, powerpc, etc. and there would not be any source-depends. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNQ6WaSqK7IlOjMLFAQEFeQQAiLbEDV1nwsJpeZY97lcjo2CGIQqilyIQ fY7WiihDYL5VunloLF9uAKurYtSfr16v79C0a8+y0yH1rVBlWQ31KlPsFx8H3J+w 5CvAW//YRBzpHpZyPVZ9otNIAEwxwCsVnkT81O0zkDJx2+sT2ROZhmsI66u3p1H6 WxA7qtAbV9k= =af3z -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Locale (Policy consult/proposal)
-BEGIN PGP SIGNED MESSAGE- On Thu, 12 Mar 1998, Luis Francisco Gonzalez wrote: For example, for german, all programs seem to use /usr/share/locale/de/LC_MESSAGES/name but unfortunately, unless you define LC_ALL=de rather than say LC_ALL=de_DE, this path is not searched automatically. Mmm, are you sure? I have LC_ALL=es_ES in my environment (and *no* LANG variable defined), and I can see spanish translations in all the localized programs. As far as I know, LANG is only for overriding LC_ALL, as a last resort. I cut and paste from GNU gettext info file: In the function `dcgettext' at every call the current setting of the highest priority environment variable is determined and used. Highest priority means here the following list with decreasing priority: 1. `LANGUAGE' 2. `LC_ALL' 3. `LC_xxx', according to selected locale 4. `LANG' -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNQgwEyqK7IlOjMLFAQHJogP/YuHMx5tZMGrrRT/Y82LjaGMopAwPQhFD 2QB5zJ8ECxxHGudZwf+RhP47T1sd7frJIKGOlwx0LgLnNj9iUo/pgPKIeIAK6V7g vTHAWS+lfDDBDn4vSvg5ByVjqkL8tQbWyYjc0ivKEIUj2sJwQSUVnx8wT/qloGo+ lXlJ2eUudyk= =sl3f -END PGP SIGNATURE- -- E-mail the word unsubscribe to [EMAIL PROTECTED] TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to [EMAIL PROTECTED]
Re: Policy about /usr/share
-BEGIN PGP SIGNED MESSAGE- file-directly-in-usr-share Hi Christian. It seems this tag is a little bit confusing. Would be possible to find a better one? For example: file-directly-in-usr-share-not-in-a-usr-share-directory -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNQLG1iqK7IlOjMLFAQHz+wP8CZaUP1flWY+/UU8RtNNxSkmVXrMPCcJM kjisz6f7rL0lcCrxn2qjc6AmOBY5BBXH7ebplCaq36KQFhCF30RMqXjf2LFIxHui eONlPYdf/bLADhDMShXDPxFCsuw9TrgWcTESD3SFgn7R9JbV+tAKRV5YVo0k4qZ/ zefBcQK4maA= =TkFM -END PGP SIGNATURE-
Re: Extending version numbering (Was: glibc_2.0.7pre1-3)
-BEGIN PGP SIGNED MESSAGE-
On Sat, 7 Mar 1998, Yann Dirson wrote:
But I do agree it would be nice to have a special syntax for version
numbers allowing to cope with {pre,alpha,beta}-like numbering. It is
perfectly sane to distinguish between it's in testing stage and
it's released software, and we should IMHO support such a thing.
Anyone against that ?
Yes, me.
Current glibc_2.0.7pre1-3 should have been packaged for experimental,
since it is not released software.
Something like 2.0.6.3 or 2.0.6.pre2.0.7-3 would have been a better
name (I use procmail_3.10.7 for procmail-3.11pre7).
Once we already have 2.0.7pre1-3, I would not mind at all having to
install final 2.0.7 by hand, without ugly epochs or rel things.
We should remember that most people have *not* upgraded to hamm yet.
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
iQCVAgUBNQEulyqK7IlOjMLFAQHFtAP/XDBv+SY+s+BJ/6TJggAVtsO5dJ8pEmBe
IBMQtukSiVQuEQBN3jof/fjm+eU21lDJpVJdYmTBHXmxuha7Lrsx393NkOqtccc4
zWrEGXZM2UA0oTNSHyW47N6qpxE2RI5YLehCyWVDIPsD732P3w5bLFxP1C6dRKOo
EEG49Vk1dUk=
=y+m3
-END PGP SIGNATURE-
Re: Bug#19048: cvs-buildpackage: they should use /bin/sh and not bash
-BEGIN PGP SIGNED MESSAGE- On 6 Mar 1998, Manoj Srivastava wrote: Herbert Yes but unless you actually require any non-POSIX features, Herbert you should use /bin/sh (this is specified by the policy). Herbert And currently I don't see anything like that in your scripts. Where? I do not see this in policy. __ The standard shell interpreter ``/bin/sh'' may be a symbolic link to any POSIX compatible shell. Thus, shell scripts specifying ``/bin/sh'' as interpreter may only use POSIX features. If a script requires non-POSIX features from the shell interpreter, the appropriate shell has to be specified in the first line of the script (e.g., ``#!/bin/bash'') and the package has to depend on the package providing the shell (unless the shell package is marked `Essential', e.g., in the case of bash). Restrict your script to POSIX features when possible so that it may use `/bin/sh' as its interpreter. If your script works with ash, it's probably POSIX compliant, but if you are in doubt, use `/bin/bash'. __ Where does it say I *have* to use /bin/sh? It tells me to stick to POSIX features so it _could_ be used with /bin/sh. Nothing says I have to use /bin/sh. As far as I know, Restrict in the above paragraph is a verb in imperative form. There is no point in trying to make a script POSIX compliant so that it may use `/bin/sh' as its interpreter if you do not end up actually setting /bin/sh as its interpreter when it is possible to do so. I think the policy is very clear about this, since it says at the very beginning: The *standard* shell interpreter ``/bin/sh'' ... This means /bin/sh is the rule and /bin/bash should be the exception. The policy also says when you have to use the exception: Only when the script uses non-POSIX features. It is true that policy says in doubt, use /bin/bash, but if somebody tells you it works with ash, I think you should believe him at least. I have no idea why you are on this crusade; but leave my packages out of the /bin/sh politics. Or change policy. The policy have already been changed to encourage /bin/sh over /bin/bash. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNQEzBSqK7IlOjMLFAQFA1wQApHqjHDmkxtjJTHzcsJMpBXImasklweN/ 6iUPP0MIICFkTuYzdVneQwSTmg3Jlc7AL35zmB2Glk0jhZ5h4T1xi0cv7ucJfja7 7QrngAf92gCYV/VASbeyBiVJ2Wh9P933qjt4XmyhUdYIxLMcuE1+k0f4VkYthIyV EBAI1UnaE0c= =IPbN -END PGP SIGNATURE-
Re: Bug#19048: cvs-buildpackage: they should use /bin/sh and not bash
-BEGIN PGP SIGNED MESSAGE- On 7 Mar 1998, Manoj Srivastava wrote: using /bin/sh is just waiting for a problem to occur, Oh, yes, removing the /usr/spool symlink is also waiting for a problem to occur... That argument does not convince me at all. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNQGRXiqK7IlOjMLFAQH4WwQAsqdZLlnKx8uWXCaFcKKVV8ykr8MbAN7g Ho8hFQgUESJQRRu8pjoZWkxDqFAh6V11Edc0pyqTiMEJ1gyZGzF3hzSEQf19L9lg 3I7d/NA49ppDdHJnoPs+zyYBjVpErkwuRgt9bR1heHG0STAAHWuTRi0sGlqS5yPp E+cAC9emfT8= =Zc0E -END PGP SIGNATURE-
Re: Bug#19048: cvs-buildpackage: they should use /bin/sh and not bash
-BEGIN PGP SIGNED MESSAGE- On 7 Mar 1998, Manoj Srivastava wrote: Anyway, bash is essential, /bin/bash shall always be there, using /bin/bash shall never cause any problems, That argument is also not convincing at all. If you really believe what you are saying, then please suggest a change in the policy so that /bin/bash is *always* recommended. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNQGUvCqK7IlOjMLFAQFm3wP/beIK48/xwCzoXdPFdKjPTNwlVPfxCJD3 P5Xxq5vTHTtCaAkSCef9ZlKxC2uL2+o5C/roPl8Zbyzi8VQ8oKiPuSPLbE1OHl6d azH+aAYU2PPq19d5/Nc7rGnysToeLHbj2R8uyzMzFFTvESHc5bZm1rhEWI6mInLX GUq6VDtoTSg= =LNpi -END PGP SIGNATURE-
Re: lintian: symlinks from /usr/lib into /lib
-BEGIN PGP SIGNED MESSAGE- On Fri, 6 Mar 1998, Yann Dirson wrote: Package: lintian Version: 0.3.0 E: e2fslibsg-dev: symlink-should-be-absolute usr/lib/libe2p.so ../../lib/libe2p.so.2.3 N: N: Symbolic links into /etc or /var should be absolute. N: N: Refer to Policy Manual, section 3.3.5 for details. N: Neither the policy nor the packaging manual do say anything about the quite common case where a lib is in /lib/, and its dev link in /usr/lib/. On my installation, all such links are relative, so I suppose it's not a mistake from me, and it is probably a lintian bug, or is there really a reason of using absolute links there ? I'm afraid there is one: /usr may be a symlink to somewhere else. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNQBhWiqK7IlOjMLFAQFiRgQAkCl3SyXHGlamSyGRd69+e7dEscJgrRNM Vdh/Keyntx6DeF/k2jIO6iulEy9VmXb1avVhvAynrOyc/z6HbkOurM96Ob+2T77H m+nlePaUMFsCw0QzyS1YzIK+e1SGjukxvsNYe07boGopV1SGR9ZP1CkX0aARYDxo tKRvAvde1OI= =fILP -END PGP SIGNATURE-
Re: glibc_2.0.7pre1-3 uploaded to master
-BEGIN PGP SIGNED MESSAGE- On Tue, 3 Mar 1998, Christian Hudon wrote: On Tuesday, March 03, Dale Scheetz wrote Format: 1.5 Date: Sun, 1 Mar 1998 19:02:48 -0500 Source: glibc Binary: timezones libc6 libc6-pic libc6-dbg locales libc6-doc libc6-dev Architecture: source i386 all Version: 2.0.7pre1-3 Ugh. There really should be something in the Policy Manual against using 'pre'. It doesn't seem to be a widely known fact, but according to dpkg: $dpkg --compare-versions 2.0.7pre-3 lt 2.0.7-4 || echo 'Uhoh... 2.0.7pre-4 2.0.7-5' Huhoh... 2.0.7pre-4 2.0.7-5 Yes, this is explained in the packaging manual, chapter 5, Version numbering. The interesting paragraph is this: If an upstream package has problematic version numbers they should be converted to a sane form for use in the Version field. ...which is what has not been done in this case. However, I, for one, would prefer having to install once glibc 2.0.7 by hand than having this rel thing in the frozen or stable hamm. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNPw0eyqK7IlOjMLFAQFd1gP/a1uScXngPnuCsZeTCSsVm+bvXg8jRB6G 0/Rp3fL6CQgbdneOC/n2rVX74y1CPD8RZ1MZ1l+NVm6ZO4buDkHSFWs5YJ4jcGdC ZPk7YfcV7ozV4DYOla9Pk7ity6/Ekwc8uycPoUdWvJR6XBKOUUBW5Qdgtfgm0USL brWz4Lw3Ia4= =gjaw -END PGP SIGNATURE-
Re: policy violation and bug reports. - some resolution?
-BEGIN PGP SIGNED MESSAGE- On 25 Feb 1998, James Troup wrote: Joey Hess [EMAIL PROTECTED] writes: Anyway, I think this is a bug in dpkg (not asking about removed conffiles) and I don't think it is right to make a program to benefit from bugs in other programs... I've always hated this behavoir, but it's my understanding it's intentional (a feature, not a bug ;-). However, note that dpkg will not replace a conffile that was removed by the user (or by a script). This is necessary because with some programs a missing file produces an effect hard or impossible to achieve in another way, so that a missing file needs to be kept that way if the user did it. (Packaging Manual 9.1) Yes, this is what dpkg currently does. But being documented does not mean it is always a good idea. I didn't say it was an error not to *replace* a conffile when it didn't exist. I said (IMHO) it was an error not to *ask* the user about creating a new file or leave the file in its inexisting state. If dpkg asks about keeping the conffile in place or replacing it with a newer version, it should also ask the user about keeping the file in inexistant state or create a new one. The current behaviour is clearly not appropriate for many configuration files. BTW: I had a bug report against base-files for not creating /root/.bash_profile when it did not exist... Yes, this only proves that conffiles are not appropriate for /root/.bash_profile... -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNPVBayqK7IlOjMLFAQGJBQQAqJRhBLZr1J8WN9X8c9Qv4ICY8rScWXR2 xCdjSNlIym3crvNEq9p1HzHT5jfj29EiY9uS2NFERp1RlO6D7cKNbbcvjHg/aMKF AXp+8oJE73YyVPZxvA9VzKMORBiKghEDEbXWFCyugrCRitIFpLBAATRnr/mwNEJ+ PMnLqghpync= =bwqk -END PGP SIGNATURE-
Re: policy violation and bug reports. - some resolution?
-BEGIN PGP SIGNED MESSAGE-
On 24 Feb 1998, Manoj Srivastava wrote:
There is no need for conffiles in /root; I'd be happy to
provide patches to the postinst if the maintainer feels unsure about
coding it.
I mostly agree. Current base-files_1.7.postinst now says:
#!/bin/sh
install_from_dpkg_dist() {
if [ ! -f $1 ]; then
echo Installing $1 from $1.dpkg-dist ...
cp -p $1.dpkg-dist $1
fi
}
install_from_dpkg_dist /root/.bash_profile
install_from_dpkg_dist /root/.bashrc
[...]
This is already No fuss, no muss, no questions, no over write.
Does this violate any current policy?
Why should I include those files in the postinst?
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
iQCVAgUBNPQcCSqK7IlOjMLFAQH2qAP/Z+rSU1bE6dPawdAMhOXMtONC9rpvdKJU
aowPLCXPSTNvdk7+PFUSbYeQ2OSKARsXWdBV8DOL7Te3ZU1moLd9DDA1zIS4mvei
Mb3Ls9t/1OqW6BINDAtFT3Z9X+tEzSZTKOKTHwrf3L8uEo86p+Z77V/bP2l3X+UM
8LLSQk7X58M=
=BxKN
-END PGP SIGNATURE-
Re: policy violation and bug reports. - some resolution?
-BEGIN PGP SIGNED MESSAGE- On 25 Feb 1998, Manoj Srivastava wrote: the default files are puerile [...] If you must have these files to copy into /root, keep them in /usr/lib/basefiles (which is not in the root partition) [...] Mmm, should I create a subdirectory in /usr/lib for puerile files? :-) What if I simply remove these files in the postinst? Is /root/.bash_profile.dpkg-dist so difficult to remove by hand that I should move it to somewhere else or hide it in the postinst completely? What do others think about this? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNPRjgCqK7IlOjMLFAQHLRQP/eXx8Rb/EHzFLfYA906yrWndRXDiS9s3T is1mEPRbI/CEIpqWkwHFPpivcWIrhDwqfVJg15Vv5w0Pv8CBrJojo3KqaouAIJuE W7VWgwhnIthchuFgWTbKbSC7opOfoz9J5oqa5A2S8K02g2Ic9sk7dP5JKMKW2Br/ HaeZ26Jw48c= =oUWk -END PGP SIGNATURE-
Re: policy violation and bug reports. - some resolution?
-BEGIN PGP SIGNED MESSAGE- On Wed, 25 Feb 1998, Joey Hess wrote: Manoj Srivastava wrote: Compared to that, the default files are puerile. It is annoying to have little control over my home directory as root, and b) have to delete those files over and over again since they mess up ls -asCF output. If they were conffiles, you could delete them once and never see them again (dpkg doesn't replace deleted conffiles ever). You are right, but having a .bash_profile.dpkg-dist.dpkg-dist would be too much :-) Anyway, I think this is a bug in dpkg (not asking about removed conffiles) and I don't think it is right to make a program to benefit from bugs in other programs... -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNPR0iyqK7IlOjMLFAQE3uwP9FnFgVLHzi/sL9/VmTcsHTJrzEFZADnk1 k9QIpq9OCeoHcqDeVxoeBABX7ULgFchEdYXfIjVpFbF9h8AObHcHdB6alhwWNwLE CdsrnD7t+a2rEAV8mpHBcW/h+MAo+qlFyImAVGm5BqgcRLINw5XH7r0aUbk4Fu1F /+ydepLz7Lg= =Wuih -END PGP SIGNATURE-
Re: /usr/lib/perl5 - /usr/share/perl5 ?
-BEGIN PGP SIGNED MESSAGE- On Thu, 19 Feb 1998, Gregor Hoffleit wrote: perl5 installs its modules that are AFAIK architecture-independent into /usr/lib/perl5. Shouldn't this be /usr/share/perl5 according to FSSTND? No according to FSSTND. But yes according to the FHS. We are not moving to FHS yet (Debian 2.0). This means there is no need to change it if it is currently in /usr/lib. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNOwsLCqK7IlOjMLFAQEudQP/ejRhUKMe7BMKPaW6T5ydwU5iU+HTsLAf +yd/w2025wB3oxSlLF5XbR6i1EUoiLq8oMeaZZgEjBrkyXqpiyvGuq1nSXcPeBZi 9Dbb6m1fNe66zPjBEKulsEfYtR9g6SjeyfBjEVlsx7NZepS6kxxFD0kDRnirVl39 FHKIZgXW6M4= =YAAX -END PGP SIGNATURE-
Re: essential packages and Pre-Depends
-BEGIN PGP SIGNED MESSAGE- We should remember that dpkg *does* allow a package to be installed when the *Dependencies* are not satisfied. Example. In a pure bo system, the following may happen: # dpkg -i diff_2.7-15.deb [ This is the diff from hamm ] (Reading database ... 15191 files and directories currently installed.) Preparing to replace diff 2.7-13 (using diff_2.7-15.deb) ... Unpacking replacement diff ... dpkg: dependency problems prevent configuration of diff: diff depends on libc6; however: Package libc6 is not installed. dpkg: error processing diff (--install): dependency problems - leaving unconfigured Errors were encountered while processing: diff Of course, diff is now unpacked, but it does not work at all. We have told our users that our packaging system is robust. But the packaging system in this case allowed an essential package to become completely broken. I don't want to discuss here whether diff should or should not be essential [ Currently it is ]. I'm saying that there must be something really wrong if we consider that a given package is essential and at the same time we allow this to happen without using any --force-whatever option of dpkg. Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNOwxjCqK7IlOjMLFAQGwEwP9HpoIk9jKUa96ndWKTWcPy7PtYc68vov4 3lsRdPqRMGurzzp7zpXvm1dspD/9ojbC6BR8Ld4jOnlyW/wJ0z1zLShGwyI/Pk5z gxgNwnNwz7x1zVO3HbMuLv5SkJy3LFaZbOm9Y25/jLgfxn82tt9Y5HRVr/d5vdw2 w2xeaR/ck74= =V5/0 -END PGP SIGNATURE-
Re: awk: essential virtual package?
-BEGIN PGP SIGNED MESSAGE-
On 18 Feb 1998, James Troup wrote:
Santiago Vila [EMAIL PROTECTED] writes:
[ ... ]
Perhaps we should just make mawk and gawk to Pre-Depend on libc6
instead?
With all due respect, you've 100% missed the point of making awk an
essential package, the idea is to ensure that there is always an awk
available for {{pre,post}{inst,rm} scripts etc. without the need for a
dependency. If we go out of our way for perl in the same regard, to
not to do it also for good old awk would be criminal.
No, I have not missed the point. Simply, you didn't understand the
meaning of instead. Please read.
Manoj said that base-files should Depend on awk, so that awk is
both essential and virtual. I think everybody agrees on this. [ I will
add the Depends line again in the next base-files release ].
However, Manoj suggested that base-files should not only Depend on awk
but *Pre-Depend* on awk.
But since you can not both *remove* one awk and *install* another awk on
the same dpkg run, I think that the Pre-Depends line is not needed at all
in base-files (i.e. Depends: awk is enough to ensure that awk is
*installed* on the system).
However, to ensure that awk is always present and *it always works*
(i.e. it may be used safely in {pre,post}{inst,rm} scripts)
perhaps mawk and gawk should Pre-Depend on libc6 (this is in addition to
having base-files to *Depend* on awk), since any of them may be awk, which
is essential. [*]
So *instead* of having base-files to Pre-Depend on awk, perhaps we should
make mawk and gawk to Pre-Depend on libc6 (and base-files Depend on awk).
If you read again my mail, I said I'm not sure that base-files should
Pre-Depend on awk [...]. I did *not* say instead of making base-files
to Depend on awk.
[*] Example: mawk.deb, B.deb and libc6.deb are hamm packages, which we
are going to install in a bo system. We issue the following command:
dpkg -i mawk.deb B.deb libc6.deb
If awk is currently mawk and B's preinst uses awk, it will fail.
A similar example could be made for gawk. Since any of them may be awk,
the only workaround for this is to make both mawk and gawk Pre-Depend on
libc6.
Is this clear now?
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
iQCVAgUBNOtAkCqK7IlOjMLFAQHP4QP+JUlpnZFn32nBjmmIhXb0A1aKW8qE/etK
9U3PQrXvSRplqjS49K7KrVbcUc3LeFWQYoa5h6KUbgvrF574d5ldbpmuBNiFlt7n
Op//cdMdOkhzKIoNbcYa/yDPGdPpsU4swGhWpdnHWacFZq/PjvGyw+5vVM1GtnyS
vglkzpaUNGw=
=ZueE
-END PGP SIGNATURE-
Re: awk: essential virtual package?
-BEGIN PGP SIGNED MESSAGE-
On Tue, 17 Feb 1998, Christian Schwarz wrote:
On 16 Feb 1998, Manoj Srivastava wrote:
I must admit I didn't notice this discussion until I saw the discussion
about the bug reports on this topic. Could someone please explain in a few
sentences the technical reasons behind this?
I will limit myself to repeat what I said in debian-devel:
Essential packages are supposed to work all the time, because they may be
used in any prerm, postrm, preinst or postinst script. And all the time is
*all* the time, not just between succesive runs of dpkg. Example:
Package A depends on library C, package B uses A in the preinst script.
A is essential. We issue the following command:
dpkg -i A.deb B.deb C.deb
Clearly, B's preinst will not work, because A is not configured yet.
This upgrade will be *much* safer by making A to Pre-Depend on C.
However, James Troup seems to think that there are two types of essential
packages, essential ones and really essential ones. I would like to
hear his opinion on this.
Of course I think there are just one type of essential packages and the
sole fact that a package is essential means that it may be used anywhere
in {pre,post}{inst,rm} scripts, which are also part of the packaging
system. I could not imagine a scenario in which a developer had
to think no I can't use `ps' in my preinst because procps is only
essential, not `truly essential'. Anyway, if we are going to have two
types of essential packages, it should be documented somewhere...
BTW: I'm not sure that base-files should Pre-Depend on awk, because awk is
virtual and it is handled via alternatives. This means that you can't
both remove mawk and install gawk on the same dpkg run (currently, I'm
unable to find an example like packages A, B and C above for base-files
and awk which proves that the Pre-Depends is needed for base-files).
Perhaps we should just make mawk and gawk to Pre-Depend on libc6 instead?
Thanks.
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
iQCVAgUBNOmGwyqK7IlOjMLFAQEuuwP8CbOQsOolCd9LJjmfoSHTlxjvmlTikiIh
AE4ZwZAtRf/1xPK+UITK55BeIiv0pOyRcO/p+MWdba6QmnTkR070sBCmzlpZKgjF
R8U2qTqgmhT03wDr3Jcl7HmwDQrwfK8Zn3rmNIqawvNIMyzY09pwntgU3xmYQSWz
/Hmm6Yxsdpg=
=6qWP
-END PGP SIGNATURE-
Re: awk: essential virtual package?
-BEGIN PGP SIGNED MESSAGE- On Mon, 9 Feb 1998, Christian Schwarz wrote: Santiago (base-files maintainer) pointed out that the current base-files package depends on the virtual package `awk' which makes awk `implicitely' essential. (With that it is guaranteed, that _some_ awk version is always installed, either gawk or mawk or both.) This brings up the following questions: 1. Should `awk' be an `essential' package (i.e., is it important enough so that other packages don't have to depend on it)? 2. Is there a better solution to tag virtual packages `essential'? If this solution turns out to be good, then it should probably be documented in the policy manual, and the base-files package should contain a note about the `Depends: awk' somewhere in a README.Debian file. Unfortunately, nobody answered this, so I removed the Depends: awk in base-files 1.6.1, for now. However, today I went to the mailing list archives and found this message from Chris Fearnley: *-- To: debian-devel@lists.debian.org Subject: New gawk and mawk packages uploaded, finally From: Chris Fearnley [EMAIL PROTECTED] Date: Thu, 8 Aug 1996 18:37:14 -0400 (EDT) [...] I got new gawk and mawk packages uploaded. [...] Neither package is essential. Both provide an 'awk' package. Mawk is section base, priority important. I didn't include section or priority information on gawk since I'm not sure of its final resting place. The base package maintainer should make 'base' depend on the virtual package 'awk'. Thus users can use mawk, gawk, or both. I recommend mawk because it is fast and small (See Arnold Robbins comments in the August 1996 issue of Linux Journal). [...] *- The interesting phrase is The base package maintainer should make 'base' depend on the virtual package 'awk'. I could not find anything more about the issue in the archives (perhaps this was discussed even before the archives started). It was our intention (at that time) to make awk a virtual essential package? If yes, was it dropped? There is an atonishing low number of packages having a Depends: awk. Should somebody start filing bugs against packages which depends on awk without declaring the dependency? Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNOh2qyqK7IlOjMLFAQFh6AP+IfCEl5bisOb4AZMxHFDHXT9SzM7DGzO/ s17THO7g+2K9jNzhtZ4zp6fcPCG7N6gJwddmKkvDZrPz8L2q89D36IadwNqPMf/W pUpc6H1N3Xq4PzCDVPUgWgzbPFg4E1v6c/1ADbhMjScJWENISfBuWtLvmcodSrs6 /i/f/nsWDNI= =ZuBn -END PGP SIGNATURE-
Re: essential packages and Pre-Depends
-BEGIN PGP SIGNED MESSAGE- [ moving to debian-policy ] On 16 Feb 1998, Manoj Srivastava wrote: Santiago Package A depends on library C, package B uses A in the Santiago preinst script. A is essential. We issue the following Santiago command: Santiago dpkg -i A.deb B.deb C.deb Santiago Will B's preinst always work? I don't think so. This upgrade Santiago will be *much* safer by making A to Pre-Depend on C. I agree. [...] What do others think about this? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNOiz9SqK7IlOjMLFAQERRQQAlC2cAUS7TqCpuvsOto9Qg/PdhzxMJGAZ xYfJErA8bjIjPEGhUapT/vKjwpQoT+/GQl+9P+1FgszkspAS6R6IZzLTvXynfhpS wODXGR+7pcx0odAuTHnaPCf7v+qESaLfXL/MsfTzuvJazmTxXXs+pJBFVEaR7xXc McPs9giRa2Y= =Acz+ -END PGP SIGNATURE-
Re: awk: essential virtual package?
-BEGIN PGP SIGNED MESSAGE- On 16 Feb 1998, Manoj Srivastava wrote: The only bug is that the base-files maintainer dropped the depends line without understanding the consequences. The base-files maintainer asked Christian about the issue, who then asked in debian-policy, and NOBODY answered saying yes, this is the right thing to do, so he then removed the depends line because it had not been discussed. Should I then suggest the base-files maintainer a little more of understanding and a little less of asking in the lists first? ;-) I don't think so... Thanks. BTW: I also agree that awk should be essential, so if I don't hear any objections, I will file that bug report against base-files, if nobody else does it... -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNOi3WCqK7IlOjMLFAQFyPAP9Enq4CsrWyjUUHyrCyKpMgJUe0MwS7rMU 6UxNzScLAO0X0WNju554bium+58gcDeOT6kVorjq9GPyeoVGcEWQGNv5+T7LRyfj HcyTLur44Bey5HFnkIBCdrXSw3hkTakoOJCBwFsnnmWRwp0PgWVvRAo93Dpw3ZT/ QV+AKsOJjhE= =JTSt -END PGP SIGNATURE-
Re: `du' control files
-BEGIN PGP SIGNED MESSAGE- On Fri, 13 Feb 1998, Scott Ellis wrote: On Fri, 13 Feb 1998, Christian Schwarz wrote: With the new lintian check I discovered that some packages install a `du' control file (contains the output of the du command). Does someone know which program is using these files?? If there is no good reason for these files, should we consider this a bug? (IMO, yes.) They are created by the debhelper program dh_du. They're useful for figuring out how much space on each of your filesystems a package is taking up, especially useful if one filesystem is getting cramped. Like the md5sums file, I wouldn't judge their presence either way. You may figure out how much space on each of your filesystems a package is taking up without the need of those files... Just write a program which uses /var/lib/dpkg/info/package.list as the input data. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNOR2LCqK7IlOjMLFAQHOLQP+J3L3Q7laLSVmqIgizpPWxyvnZHVgEe3X ifZwGMPX6JE1abgaCPnZDgSKwu5ivx5S05fQjvtFZpeFtR8Y3S6TaOO7Lqo3wXZP i7Hi+tl/ebu7I30J48R1Q+Zi/a8yaElsIFtUf6fzwa73TO8LRKS19rHZ2IOOdvP+ iA8tbOAoCdc= =TKXx -END PGP SIGNATURE-
Re: `du' control files
-BEGIN PGP SIGNED MESSAGE- On 13 Feb 1998, Davide G. M. Salvetti wrote: They are useful to check how much disk space is needed under each directory before installing a package; Are you *so* short of disk space that the standard head: Installed-Size: 200 is not enough? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNOSL0iqK7IlOjMLFAQHQEwQAhsOGMwJXVoQD/b3dWhI+TTjzxFaIld4f CPkTNAFtRcPyfiRFJPEyTCf5Q80RzFGJEFCLLFxftfED7uTDfQGPIHfRHNzYhKqy 5BEzUU3tvIDNj6H5n0WcwGrH7q52udXXz92HtEuuKzosNGDVr9iJcXo7vw+/XPeM Ez0TFcOUF8c= =sHnV -END PGP SIGNATURE-
Re: #17544: /var/preserve does not exist
-BEGIN PGP SIGNED MESSAGE- On Mon, 9 Feb 1998, Remco Blaakmeer wrote: On Mon, 9 Feb 1998, Santiago Vila wrote: Is there any Debian package that actually uses /var/preserve? No, but according FSSTND 1.2, vi, ex and their clones (should) use it to store temorary files that should be preserved when the system is rebooted. Currently these are stored under /var/tmp, which is not emptied by default. Yes, FSSTND 1.2 does also say that Linux does only run under i386... As of this time, there are no different architectures for Linux I wonder if it makes sense to fully conform to such standard. I'm Cc:ing debian-policy. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNN8n2CqK7IlOjMLFAQEbOAP9F+I9JID+m1F8GjlfJ/6GG+ZyOx/hON29 JlGkTV4wbyRd4eduF5zJnAIKGyoQISuPzmr2Pe/Z4xQsH4rzMqq5uuLMs0TDbbYA +YoaVyGkCZv3pxT9mH9nCgNhpGtUi8gfOIxwodFKN98Xj481vHwIu9Z1auVacbRx LvIIX4gv3fc= =OisF -END PGP SIGNATURE-
Re: beta software ok for unstable? (was: Re: policy Q's WRT imapd)
-BEGIN PGP SIGNED MESSAGE- On Tue, 3 Feb 1998, G John Lapeyre wrote: Where can I put a package that is not dangerous, and is functional, but is still in early stages of development? What about `experimental'? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNNdsICqK7IlOjMLFAQFOYQP+PTMORlU+m+tR9i5ntECmqfW88EiH+/sG CwCEXS/Sjua6cqxFI7TajpvucHY7dAb/Gzp5R1kiqVLXZSTmvWeo49vQA2iW2p8f 15V9agSoikybS/9sCt0T1kZ+DbdrSCkYCzI4AV189y98abBmuRMaXIhkeqTtfQBb dh9ah1+D870= =cbSP -END PGP SIGNATURE-
Re: PW#5-3: How packages can register cron jobs
-BEGIN PGP SIGNED MESSAGE- On Mon, 2 Feb 1998, Christian Schwarz wrote: Is the following solution correct? 1. The `conffile' is _not_ tagged as conffile and _not_ included in the package tree, 2. it's created in the postinst script if that file does not already exist, 3. it's removed in the postrm script when a `purge' is selected. Looks ok. But then, how should we handle the cases where the `configuration file' exists already, before the package was installed? Should we leave this file as is Yes, because this allows a package to be pre-configured by another package or by hand before actually installing it. I have a package called `papersize-a4' which hopefully will help me a lot when I had to install Debian in a 21-computer lab. This package just creates a suitable /etc/paperconfig having a4 inside, and then libpaper does not ask anything when it is installed. and should the postrm really remove that file when a `purge' was selected? Yes, because in some way, the file belongs to the package, even if it is not inside the .deb. In addition, I think the corresponding section of the Policy Manual also needs to be corrected. Currently, section 3.3.7 Configuration files reads ``[...] It is almost certain that any file in /etc that is in your package's filesystem archive should be listed in dpkg's conffiles control area file. (See the Debian Packaging Manual). It is almost certain that any file in /etc is a configuration file. It should not have to be as certain that the file has to be managed by dpkg (i.e. conffiles). Example: /etc/papersize. [ ... ] Wouldn't it be good to list such `configuration files' (that need to be changed by scripts) in a new control field? Perhaps. BTW: I love this type of configuration files, they reduce the amount of prompting dpkg does when upgrading the package. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNNYcvyqK7IlOjMLFAQGD1wP/UtAwXbtOrloKUkNmqPPkVp4UFxKFIoYR AbZyt3Fqu1lhATNT2a8eK2VPnsh9UYBQSAHDpLRdagl1AFl/180lJ/H+8JjkBiGo 3cD8QPps060vjxq/3TdtIe5pV6LB/tTYkAlQHWG7nAHS4+a9eTHVjiY16c4N+nyo amipCldqXuY= =n2oW -END PGP SIGNATURE-
beta software ok for unstable? (was: Re: policy Q's WRT imapd)
-BEGIN PGP SIGNED MESSAGE- On Mon, 26 Jan 1998, Christian Schwarz wrote: Yes. Beta software is ok for unstable. Only critical software (i.e., programs that are likely to trash your filesystem) should go into experimental. I disagree here. If beta is not ok for stable, then it is not ok for unstable either, because unstable may become frozen and later unstable at any time. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNNYqJyqK7IlOjMLFAQE3vAQAkyel8x4X0TDpHvhMd5gXRoWKpVTy4+rq bgd/ihsRYxPkIgYlushO9kypZFyNXY/LZL6CD80aFvE/5VxBtkTZQ0anzHYng30r UAcL36ePviw1BKZmDzgSf7Xr+zAabOuYsrSLw/8UIbr3vXO1/8q3wRjCMdKhCo2w 9MRnya4xPCw= =hPY3 -END PGP SIGNATURE-
Re: PW#5-3: How packages can register cron jobs
-BEGIN PGP SIGNED MESSAGE- On Mon, 2 Feb 1998, I wrote: ``[...] It is almost certain that any file in /etc that is in your package's filesystem archive should be listed in dpkg's conffiles control area file. (See the Debian Packaging Manual). It is almost certain that any file in /etc is a configuration file. It should not have to be as certain that the file has to be managed by dpkg (i.e. conffiles). Example: /etc/papersize. Oops! Obviously that is what the ...that is in your package's filesystem archive part means... Well, I would propose the following addition to the policy: * configuration files for which it is impossible to find a common file that works for every user should not be part of the filesystem archive inside the .deb package, so that dpkg will not prompt the user again and again when upgrading the package: Examples: /etc/X11/XF86Config, /etc/papersize, /etc/passwd... The idea is that once that you have the optimal configuration file, you don't want dpkg to ask about it on upgrades anymore. BTW: Policy should say also it is a bad idea having a dummy conffile saying Factory or the like... -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNNYvgSqK7IlOjMLFAQG4SAQAtIXAQkFG6L98ouyZiqLSu5X++BnlnuuA JDZZNUYA5bSKgmlk47zcd3lBhYHfbxkmbmDO94XhXmcNCpYhvi19NSvriv+Tl2az fTfKSqamnOXoKNc4MHDuWEJLC75wAVI5GYWmW1KWsH5DSYe+36DB2mTcOlb2GfA/ 7ZrkSayoeqY= =4HP3 -END PGP SIGNATURE-
