dist-3.60-3 uploaded to ftp.debian.org
Hi, I've just uploaded dist-3.60-3 to ftp.debian.org. From the changes file: Date: 05 Jan 96 06:55 UT Source: dist Binary: dist Version: 3.60-3 Description: dist: Tools for developing, maintaining and distributing software. Priority: Low Changes: * Use /etc/news/organization instead of /etc/organization Please note that people who installed mailagent-3.44-1 and/or dist-3.60-2 shall have to remove /etc/organization manually after upgrading both packages. . Files: -rw-r--r-- 1 root root 457355 Jan 5 01:53 dist-3.60-3.tar.gz -rw-r--r-- 1 root root 4918 Jan 5 01:55 dist-3.60-3.diff.gz -rw-r--r-- 1 root root 460163 Jan 5 01:52 dist-3.60-3.deb 610fbf95e811b913ffc0f784c06ccb7c dist-3.60-3.tar.gz 3129dd63966de63e3a404340130c dist-3.60-3.diff.gz ea012df1e2b645c9a3c7b9325dfd04c4 dist-3.60-3.deb manoj -- How many Bavarian Illuminati does it take to screw in a lightbulb? Three: one to screw it in, and one to confuse the issue. Manoj Srivastava Systems Research Programmer, Project Pilgrim, Phone: (413) 545-3918A143B Lederle Graduate Research Center, Fax: (413) 545-1249 University of Massachusetts, Amherst, MA 01003 [EMAIL PROTECTED] URL:http://www.pilgrim.umass.edu/%7Esrivasta/
mailagent-3.44-2 uploaded to ftp.debian.org
Hi, I just uploaded mailagent-3.44-2 to ftp.debian.org. From the changes file: Date: 05 Jan 96 08:02 UT Source: mailagent Binary: mailagent Version: 3.44-2 Description: mailagent: An automatic mail-processing tool Priority: Low Changes: * Use /etc/news/organization instead of /etc/organization Please note that people who installed mailagent-3.44-1 and/or dist-3.60-2 shall have to remove /etc/organization manually after upgrading both packages. * gzip files in /usr/doc/examples/mailagent . Files: -rw-r--r-- 1 root root 455364 Jan 5 03:02 mailagent-3.44-2.tar.gz -rw-r--r-- 1 root root 6455 Jan 5 03:02 mailagent-3.44-2.diff.gz -rw-r--r-- 1 root root 327061 Jan 5 03:01 mailagent-3.44-2.deb e24fee4cf5a65586704949c1da460a52 mailagent-3.44-2.tar.gz 4095a66744cdf378756945e376cb143b mailagent-3.44-2.diff.gz 39544490f5a126c6a431e7ef904c6e63 mailagent-3.44-2.deb manoj -- It's morally wrong to let a sucker keep his money. Canada Bill Jones Manoj Srivastava Systems Research Programmer, Project Pilgrim, Phone: (413) 545-3918A143B Lederle Graduate Research Center, Fax: (413) 545-1249 University of Massachusetts, Amherst, MA 01003 [EMAIL PROTECTED] URL:http://www.pilgrim.umass.edu/%7Esrivasta/
Re: New ftp method for dselect
Robert Leslie writes (Re: New ftp method for dselect): Exceptions: (the ones I saw, anyway) stable/binary/net/bind-4.9.3-BETA24-1.deb debian-1.0/binary/net/bind-4.9.3-BETA26-2.deb If there are no objections I think I will rename the next version of the bind package to something like: bind-4.9.3BETA26-3.* Hopefully this will be kinder to software needing to parse package names. Well, I was going to object, but I see that you've already done it. You might like to consider reversing the change so that people can upgrade without having to invoke dpkg manually (dselect invokes it with --refuse-downgrade). I'll be posting later about how I think the FTP method should be done. Ian.
Re: Buglist
Sven Rudolph writes (Re: Buglist): Some suggestions for the bug reporting system: - It is possible to mark a message quiet in order to get it not echoed at debian-devel. Is there a way to make answers to it be not echoed too ? (e.g. by introducing a debian-bugs-quiet alias) That might be a good idea. Bruce, could we do that ? This is probably better than that horrible thing with `X-Debian-PR: quiet' in the main mail header. - Or what do you think about moving all bug-system messages to another mailing list ? - There was a suggestion that bug reports are directly sent to the package maintainer. Is this still planned ? How about having most bug reports still go to debian-devel, so that people can comment if they see something that touches on their `area', but make debian-bugs-quiet available so that the submitter can send things only to the maintainer ? Ian.
Re: apache
Miquel van Smoorenburg writes (apache): Well, my views on this are: o a /var/httpd/htdocs for the documents Remember apache can be a server for multiple domains. That's why we need a 2-level directory structure; you might get /var/httpd/htdocs-customer2 /var/httpd/htdocs-customer3 as htdocs base directory for other virtual domains. The cern-httpd package creates a `www' user and an entry in /home/www. I think this is probably a better idea. Ian.
Re: binary-alpha and binary-sparc directories
(Crosspost to -alpha and -sparc removed.) Bill Mitchell writes (Re: binary-alpha and binary-sparc directories): It seems that the Guidelines document needs updating to address issues falling out of this. One issue is whether binary packages are to be distinguished by distribution-specific naming convention (and, if so, what that convention is to be). Binary packages will need need distinguishing names if they're to be uploaded to a common Incoming directory. As Matt Bailey suggests, I think separate Incoming directories is a better solution. If we encode the architecture into the filename it will become excessively long, and directory listings will contain much useless junk. Will debian systems offer cross-compilation facilities? Will the developer of a sparc-targeted package be expected to provide an i386 build as well? If not, and some other developer provides the i386-targeted package, which of the two source packages (which may differ from one another) will be in the distribution? Debian packages can't (in general) be cross-compiled for different architectures. We can't make a requirement that this should be possible, because not all upstream source could be made to meet it. I expect that most packages would have a `primary' Debian maintainer, and that people doing ports would just upload binaries. If they need to make changes to the source they will have to work closely with the `primary' maintainer to ensure that all the sources are kept in step. It seems to me that packages will need a primary maintainer, who would be responsible for the source package, and an architecture specific maintainer for each supported binary package. One person could act in all capacities, of course, but I'd expect that at least some packages would have different maintainers for the different architectures. The way I see this working, architecture-specific maintainers with the ability to address architecture-specific bug reports and do architecture-specific testing would feed architecture-specific fixes and patches to the primary package maintainer. Primary package maintainers having, say, a sparc would install alpha or i386 patches blindly, relying on the testing done by the alpha and i386 maintainers, and issue a package revision update. Yes. Ian.
Bug#2060: dpkg and depends on version again
Erick Branderhorst writes (Bug#2060: dpkg and depends on version again): [...] The character is misleading and in practice it is interpretated by dpkg as =. I would suggest to change the syntax used in Depends/Conflict/Provides/Recommends/Suggest fields into a more intuitive way (Table 2). [...] However, changing this now will break almost every Debian installation. A way to prevent is is to prevent building new packages with Depends/Conflict/etc fields with or in it, and notify the maintainer to change this to = or =. Installation rules should remain the same until no more packages have or in it. For consistency a = character should be allowed to indicate that the mentioned version is requested. How about = = for less/greater than or equal to for strictly less/greater than for less/greater than or equal to (backwards compatibility, generates warning from dpkg-deb) = for equal to ? = is supported already. Ian.
Bug#2059: dpkg and depend on versions
Erick Branderhorst writes (Bug#2059: dpkg and depend on versions): Package: dpkg Version: 1.0.8 I installed the man package (2.3.10-6) succesfully. After that I tried to upgrade the libgdbm1 package (1.7.3-8). During installation of libgdbm1 dpkg reports about libgdbm1 conflicting with man (2.3.10-6) and that man (version 2.3.10-5) is installed. Are you absolutely sure that this is what it is doing ? Was the thing below an actual session transcript ? I find it hard to imagine where it got the `5' from ... Note that means less-than-or-equal-to in this context. Ian.
Re: binary-alpha and binary-sparc directories
Michael K. Johnson writes (Re: binary-alpha and binary-sparc directories ): Ian Murdock writes: [...] ther have to have separate Incoming directories for all supported architectures, or we'll have to have a naming scheme for all Incoming binary packages (prepending a dash and the architecture name, for example) that can be easily resolved before the packages are moved. Consider the case of independently-distributed .deb files. You don't want to make people put them into different directories if they support multiple architectures. I strongly suggest that putting the arch into the name will be a lot of help in the long term. Why can't people who want to put multiple .deb files for different architectures in the same directory rename the files ? Ian.
Bug#2081: named does not start
Michael Alan Dorman writes (Bug#2081: named does not start): In message [EMAIL PROTECTED], Jean-Marc Bourguet w rites: PS=`ps -p $PID 2/dev/null| tail -1 | grep named` You might want to make this PS=`ps -p $PID 2/dev/null| tail -1 | grep named | grep -v grep` so that it doesn't pick up the grep process as well. Don't do things like this in production code. What if some poor user's process happens to contain the string `named' ? This is what programs like start-stop-daemon are for. (I'm glad to see that the package maintainer has fixed the problem, I'm just pointing out that this kind of trick with ps may be all very well for a quick hack, but that Debian isn't just a quick hack.) Ian.
Re: Too much information! (And what to do about it.)
Ian Murdock writes (Too much information! (And what to do about it.)): With all of the new developers that are joining the Project and the number of new packages that are resulting from their involvement, it's becoming increasingly difficult, especially for newer users who aren't exactly sure what to look for, to browse the archive of packages without becoming overwhelmed at its sheer size. It's certainly great that all of these new packages are becoming available, but it's also presenting a problem for us, a problem which we need to address soon. What I propose we do is separate the distribution or system packages (those packages that constitute a complete system--definitely Base, Important, and Standard packages, and possibly Optional packages, too) from the application or extra packages that generally wouldn't be considered part of an operating system. With two such trees, the distribution would be far easier to manage. Comments? Now would be the perfect time to do something like this; many mirror sites are going to have to redownload everything anyway. In principle this sounds like a good idea. I don't have a strong opinion on whether Optional should be included in the `distribution'. However, it would be good if you don't break dselect's access methods c. These expect to find `stable', `development', `contrib' and `non-free' at the top level, and inside each a `binary' directory and in there a `Packages.gz' file. If you could make the split under there, by splitting each section into two directories, that would work better, I think. I think we should discuss this a bit before it gets done. Ian.
Re: Bug#2091: creating packages requires root privileges
Marek Michalkiewicz writes (Bug#2091: creating packages requires root privileges): To create a binary *.deb package, root privileges are required. This is because you must create a complete directory structure with proper ownerships and permissions first, and then use dpkg-deb to create a package from it. Unfortunately there's not much that can be done about this, because most packages are created by running the package's own Makefile to install the files. This doesn't work (or fails to DTRT) if you're not root. I have no plans to improve this situatioon; I think the simplest solution would be a way to mount a part of a filesystem in a way that means user uid is root for here. You'd want to mount it with nosuid,nodev of course. Then the filesystem could be used to record the chmod's c done by the package build Makefiles and get them into the .deb file. If someone else wants to write a program that makes .deb files some other way then they should feel free. They'll probably want to make the `new format' archives the default - see the dpkg-deb source for details. I'm closing this bug report. Ian.
Re: FTP site performance low
Matthew Bailey writes (Re: FTP site performance low): [...] Well netscape corp screwed me with politics and listed me in their mirror listings. Well there used to be more mirrors but it seems that we are one of three listed now. And until beta 5 or release version are out I can not get out of their list. And I can not remove their software until this happens. Well, you seem to be more tolerant than me. I hope they're paying you well for the privilege of being swamped for their commercial benefit. If they're not I'd just say to them Either you take me out of that list by date or I remove Netscape. Up to you. But then I'm a bastard :-). Ian.
Re: Bug#2059: dpkg and depend on versions
Ian Jackson wrote: Note that means less-than-or-equal-to in this context. Could dpkg also support using = for this meaning please? (Or does it already?) Having to write to mean = is far from optimal; I think it's something we should aim to get away from at some point. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#2097: Problem building dvips
Package: dvipsk Version: 5.58f I obtained the sources from ftp.debian.org within the 0.93R6 directory tree, and tried to recompile simply using the command: debian.rules build The first thing that had to be fixed was to go and fetch the kpathsea sources, since one can't compile dvipsk unless one also has those sources on disk, in a particular directory sequence. But the more fundamental problem is that these sources seem to be looking for the new version of the C libraries: ed: can't load library 'libc.so.5' whereas the stock 0.93R6 distribution includes only libc.so.4. (This whole problem came about because I'm trying (but failing) to get color output from dvips. In trying to make it work, I had downloaded several version of color.pro, colordvi.sty, etc., etc., and since none of these worked, I wanted to replace my dvips files with the original ones that came with the dvipsk distribution. At the same time, I wanted to look into the sources to see if there was any info in there to help.) I'm not sure this is a bug that's worth fixing, since ELF is well on its way, but I thought it might at least be worth reporting. Susan Kleinmann [EMAIL PROTECTED]
Re: binary-alpha and binary-sparc directories
(Gigantic crosspost trimmed.) Raul Miller writes (Re: binary-alpha and binary-sparc directories): It does look like dvips was superceeded by some other package, and that it did originally have some executables in it. [All I have on my system from dvips is a copyright statement and some .tex files]. makeidx, metafont and xdvi also seem to be mere stubs of packages on my system. dvipsk should have a Conflicts line to ensure that dselect/dpkg will remove dvips. /usr/bin/fort77 is a perl script, the only other things I see in this package are a man page and a copyright statement. Since I have f2c on my system as a separate package, I'd guess that fort77 has also been superceeded... Again, a Conflicts line would have done the right thing. I think this is a bug in the debian packaging mechanisms. Well, I could change dpkg so that it would barf in this situation, rather than going ahead and removing the files from the earlier package, but I think that would have been less helpful. Ian.
Bug#2080: cern-httpd or dpkg leaves log files after purge.
David H. Silber writes (Bug#2080: cern-httpd or dpkg leaves log files after purge.): Package: cern-httpd -or- dpkg Version: ??? 1.0.7 After purging cern-httpd from my system, the log files remained. The logfiles will be created by the package, so dpkg doesn't know anything about them. It is cern-httpd's responsibility to clean them up. Thanks, Ian.
Bug#1995: run-parts on laptops
Raul Miller writes (Re: Bug#1995: run-parts on laptops): Ian Jackson: Perhaps savelog should be moved into another package, then ? This seems like a very good idea. miscutils is probably the right one. Ian.
dselect FTP method and dftp wrt FTP site organisation
While thinking about this problem over the Christmas break I have come to the conclusion that we do not have to change the filenames so that we can recover the package name and version information from them. Programs can use the Packages file to avoid downloading files that they know they don't want (because of the Filename field there). If a package has just been moved into view and the Packages file isn't up to date yet then they will have to download just enough of the package to get the control information and can then abort the transfer. Because most of the schemes for making the filenames contain the package name and version without any ambiguity are ugly in some respect I'm inclined to say that this is what we should do. There is another problem with encoding things like this: it means that if at some later point we want to put some new information in the filename (such as the target architecture) we can't do it because it will break dftp and the dselect FTP method. There are a couple of things I want to set people straight on, in this area: * dpkg and other packages written especially for Debian don't have a revision number because a revision number would be meaningless and confusing. The most recent guidelines say not to use the Revision field anyway (as it will be phased out soon) and say that only packages not written specially for Debian shouldn't have a -revision component in their Version field. * Changing the format of version numbers in existing packages causes problems, because dpkg can't tell whether the package is a downgrade and so can't tell whether to install it. * Noone (hopefully) is proposing changing the actual package names (as seen inside the package control file), so consideration of Provides fields as a backwards-compatibility measure is missing the point. Changing package names is quite a serious and risky operation for an already-installed system, and should be avoided where at all possible. * Someone said that we don't need to parse the version number out of the filenames. They were wrong. dftp and the dselect FTP method need to know the version numbers of packages they're thinking about downloading, so that incremental upgrades don't have to fetch all the selected packages but only the changed ones. * There is little point trying to keep our filenames completely consistent with the upstream maintainers'. In fact, upstream maintainers' filenames are frequently very inconsistent across packages, and we want to present a consistent filename format for neatness. * If we do want to rename all the .deb files we don't have to do it all at once and screw up the mirrors. Just rename half a dozen files each day until they're all done. * Revisions are allowed to contain `.' characters. See the packaging guidelines. * A SITE EXEC command is no good because we can't rely on it being supported everywhere. It's also quite inefficient. * Bruce said: Once we decide on a package naming standard, we should tell the rest of the free software world what it is and encourage the upstream maintainers to stick to that format. There already is a de-facto standard for general naming of upstream source packages - it's the one used by the GNU people, package-version.tar.gz. Ian.
Re: dist-3.60-3 uploaded to ftp.debian.org
Manoj Srivastava writes (dist-3.60-3 uploaded to ftp.debian.org): * Use /etc/news/organization instead of /etc/organization Please note that people who installed mailagent-3.44-1 and/or dist-3.60-2 shall have to remove /etc/organization manually after upgrading both packages. Can't you fix this up in the postinst ? Ian.
Bug#2060: dpkg and depends on version again
How about = = for less/greater than or equal to Ok for strictly less/greater thani Ok for less/greater than or equal to (backwards compatibility, generates warning from dpkg-deb) Ok but an fatal error from dpkg-deb would be better than just a warning. = for equal to -- Erick [EMAIL PROTECTED] +31-10-4635142 Department of General Surgery (Intensive Care) University Hospital Rotterdam NL
Bug#2059: dpkg and depend on versions
Erick Branderhorst writes (Bug#2059: dpkg and depend on versions): Package: dpkg Version: 1.0.8 I installed the man package (2.3.10-6) succesfully. After that I tried to upgrade the libgdbm1 package (1.7.3-8). During installation of libgdbm1 dpkg reports about libgdbm1 conflicting with man (2.3.10-6) and that man (version 2.3.10-5) is installed. Are you absolutely sure that this is what it is doing ? Was the thing below an actual session transcript ? I find it hard to imagine where it got the `5' from ... Yes, I'm sure, the transcription was in chronological order. I didn't understand the `5' either. I was thinking that perhaps the was causing it? Is the conflicting version number calculated from (2.3.10-6) or is it displayed right away after reading it from the status file. I should have send the status file probably but I think it is too late now. Note that means less-than-or-equal-to in this context. Ian. -- Erick [EMAIL PROTECTED] +31-10-4635142 Department of General Surgery (Intensive Care) University Hospital Rotterdam NL
Unanswered problem reports by date
The following problem reports have not yet been marked as `taken up' by a message to [EMAIL PROTECTED] or or `forwarded' by a message to [EMAIL PROTECTED] OVER 10 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Package maintainer 416 wenglish perl doesn't flush output auto (unknown -- `wenglish') 563 tartar -x fails to overwrite or c Bruce Perens [EMAIL PROTECTED] 579 image (?) missing /usr/man/man8 manpages (unknown -- `image') OVER 9 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Package maintainer 660 gdbGDB gets address of structure (unknown -- `gdb') 662 procps top doesn't behave sensibly if Bruce Perens [EMAIL PROTECTED] 691 textutils textutils package, fmt(1) prog Bruce Perens [EMAIL PROTECTED] 702 findutils locate crash with large db Bruce Perens [EMAIL PROTECTED] 713 mh mh should pause after printing (unknown -- `mh') 725 xbase twm places windows incorrectly (unknown -- `xbase') 729 procps Bizarre corrupted output from Bruce Perens [EMAIL PROTECTED] 731 ncursesncurses wgetnstr doesn't work (unknown -- `ncurses') 740 xbase xclock leaves `droppings' in i (unknown -- `xbase') 746 cpio mt doesn't support setblk (and (unknown -- `cpio') 759 kbd, xbase /usr/bin/X11/showfont conflict Bruce Perens [EMAIL PROTECTED] 773 xbase xmh falls over if mh is not in (unknown -- `xbase') 775 xbase twm reports errors on incorrec (unknown -- `xbase') 783 tartar --same-order doesn't work Bruce Perens [EMAIL PROTECTED] 785 cpio mt problems(unknown -- `cpio') 786 syslogdsyslogd gone awol (unknown -- `syslogd') OVER 8 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Package maintainer 797 (base) /etc/termcap console keydefs f (unknown) 798 svgalibsvgalib gets control key mucke (unknown -- `svgalib') 808 emacs Info anchors not active in ema (unknown -- `emacs') 817 tartar -T /dev/null extracts whol Bruce Perens [EMAIL PROTECTED] 818 bash bash builtin `echo' doesn't ch Bruce Perens [EMAIL PROTECTED] 819 tartar should have null-separated Bruce Perens [EMAIL PROTECTED] 820 tcsh tcsh builtin `echo' doesn't ch (unknown -- `tcsh') 821 shellutils /bin/echo doesn't check write Bruce Perens [EMAIL PROTECTED] 822 tartar -t doesn't check write err Bruce Perens [EMAIL PROTECTED] 824 cpio cpio should have non-verbose, (unknown -- `cpio') 825 trntrn warning messages corrupt t (unknown -- `trn') 827 libc or sh who reports wrong hostname (wa (unknown -- `libc') 835 sysklogd syslogd dies, leaves system un (unknown -- `sysklogd') 836 (base) Possible bugs in termcap syste (unknown) 841 ncursesdselect from dpkg 0.93.34 says (unknown -- `ncurses') 844 manpages readdir(3) should document str (unknown -- `manpages') 845 manpages access(2) is ambiguous (unknown -- `manpages') 850 indent [indent] option mentioned in d (unknown -- `indent') 853 shellutils `nice' does not do anythingBruce Perens [EMAIL PROTECTED] 857 gs_bothgs (2.6.1pl4-4) doesn't use /e (unknown -- `gs_both') 864 make make gets MAKEFLAGS wrong (unknown -- `make') OVER 7 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Package maintainer 887 xarchieR6 xarchie barfs when ftp closes (unknown -- `xarchier') 889 info Info 3.1-6 (unknown -- `info') 902 lprlpr can't print a PostScript f D.J. Gregor [EMAIL PROTECTED] 903 (base) /dev miscellaney (unknown) 911 libc libc causes rsh to fail on com (unknown -- `libc') 918 miscutils mkboot and image packages (unknown -- `miscutils') 927 ncurses? dselect display bug(unknown -- `ncurses') 932 pine Pine over-encodes files and au (unknown -- `pine') 933 pine Pine wants to post my email re (unknown -- `pine') 934 pine Pine `Full Header Mode' when r (unknown -- `pine') 944 sysvinit clock (-u) question(unknown -- `sysvinit') 945 (base) clock (-u) question(unknown) 957 dpkg dpkg should automatically log (unknown -- `dpkg') OVER 6 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Package maintainer 981 ircii irc package should ask for def (unknown -- `ircii') 985 manpages struct dirent is not documente (unknown -- `manpages') 988 bsdutils `script' is insecure, and gene (unknown -- `bsdutils') 991 libc libc unknown server error (unknown -- `libc') 997 (base) Root Help Information Scrolls (unknown) 998 (base) Can't Configure DOS Partitions (unknown) 1000 (base) Reconfiguring and Duplicate En (unknown) 1002 (base) Shell Help Text: / vs. /root d (unknown) 1003
file naming convention for debian package files (was: Re: dselect FTP method ...)
Ian Jackson [EMAIL PROTECTED] said:
There are a couple of things I want to set people straight on, in this
area:
* dpkg and other packages written especially for Debian don't have a
revision number because a revision number would be meaningless and
confusing. The most recent guidelines say not to use the Revision
field anyway (as it will be phased out soon) and say that only
packages not written specially for Debian shouldn't have a -revision
component in their Version field.
I'm not religious on this issue, but I'd prefer it if a revision (or,
equivalently, a hyphen-delimited revision suffix of the version number)
were a required part of the package name. Authors of packages which
originate under debian could arbitrarily choose 0 or 1 for the revision
for debian packaging purposes. I don't see any advantage in introducing
an unnecessary irregularity into the package naming and versioning
scheme over this.
[...]
* There is little point trying to keep our filenames completely
consistent with the upstream maintainers'. In fact, upstream
maintainers' filenames are frequently very inconsistent across
packages, and we want to present a consistent filename format for
neatness.
However, keeping package names consistent with the upstream maintainer's
naming is not prohibited by the Guidelines. In fact, I suspect that this
practice is more the rule than the exception.
[...]
* Revisions are allowed to contain `.' characters. See the packaging
guidelines.
Ouch -- but correct. The latest Guidelines file I have says, in part:
debian_revision indicates which `debianisation' this is (this should
usually be a plain number, or perhaps two numbers separated by a full
stop).
I say Ouch because this makes parsing filenames much more difficult
than would be the case if the '.' character were not allowed in
the Revision field.
No packages currently seem to be using a full stop ('.') in the REVISION
field. I suggest that the section of the Guidelines having to do with
control file fields used for package naming be changed to read something
like the following:
[...]
The required fields in the control file are the following:
PACKAGE: Short name of package
VERSION: Original version number `original_version'
REVISION: Debian package revision number `debian_revision'
MAINTAINER: Name and e-mail address of package maintainer
DESCRIPTION: Description of package
The contents of the PACKAGE, VERSION, and REVISION fields will be used
to generate filenames by the installation tools, and therefore must not
contain any embedded whitespace or slashes.
The PACKAGE field is a short name for the package. A common naming
convention for packages which generate a single binary package is
to use the short package name used by the upstream oackage maintainer
naming his source package in this field as the binary package name.
The VERSION field should be the version number of the package. For most
packages which are not written specifically for Debian, this should be
the version number of the upstream source package. In addition to the
restriction mentioned previously that this field contain no embedded
slashes or whitespace, this field may contain no hyphen ('-') characters.
Upstream version numbers containing slashes, whitespace, or hyphen
characters must be revised to eliminate these characters. A suggested
convention for version number revision is to transliterate forbidden
characters to underscores ('_'). (e.g., debian binary packages built
from an upstream source package with a version number of 1.2-3.4/5 might
use a version number of 1.2_3.4_5 in their control files).
The REVISION field identifies one specific revision of a debian package
from among perhaps several package revisions built from the same version
of an upstream source package. In addition to the restriction mentioned
previously that this field contain no embedded slashes or whitespace,
this may contain no full-stop ('.') characters. A common convention is
for this field to contain contain a numeric or alphanumeric revision
number, and which is incremented with successive package revisions.
[... MAINTAINER and DESCRIPTION info ...]
The REVISION field is not strictly required to be present as a
separate control file field. It is acceptable to instead express
the REVISION information as a hyphen-delimited suffix of the
VERSION field. THe control field field specification:
VERSION: 1.2-3
if presented without a REVISION field is equivalent to:
VERSION: 1.2
REVISION: 3
[...]
Re: Too much information! (And what to do about it.)
Ian Jackson [EMAIL PROTECTED], in a magnificent manifestation of deity, wrote: In principle this sounds like a good idea. I don't have a strong opinion on whether Optional should be included in the `distribution'. I think that it should be a part of the distribution (on the cd), it just gives people some demarcation as to when they have a complete system as opposed to a base system. I have a complete system here (and a bit more) even though I don't have the ham radio packages installed since I'm not a ham. (Well...) On the other hand, I do have an hp palmtop, so I have the lxtools package. Neither set of these constitute part of a complete system; they are optional. They do make part of a complete debian distribution though.a at the top level, and inside each a `binary' directory and in there a `Packages.gz' file. If you could make the split under there, by splitting each section into two directories, that would work better, I think. Sounds fine to me. Darren [EMAIL PROTECTED] http://www.daft.com/~torin/[EMAIL PROTECTED] [EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996 @ Do you have your clothes on? I probably don't. Take yours off. Feel better. @ @ Sysadmin, webweaver, postmaster for hire. C and Perl programmer and tutor. @
Re: file naming convention for debian package files (was: Re: dselect FTP method ...)
Bill Mitchell writes: Bill Ian Jackson [EMAIL PROTECTED] said: Ian * dpkg and other packages written especially for Debian don't have a Ian revision number because a revision number would be meaningless and Ian confusing. [...] Bill I'm not religious on this issue, but I'd prefer it if a revision Bill (or, equivalently, a hyphen-delimited revision suffix of the version Bill number) were a required part of the package name. Authors of Bill packages which originate under debian could arbitrarily choose 0 or 1 Bill for the revision for debian packaging purposes. I don't see any Bill advantage in introducing an unnecessary irregularity into the package Bill naming and versioning scheme over this. We should require a revision number for Debian packages. Imagine someone forgets to remove -g in the Makefile and doesn't strip the executable, or some other oversight happens. You need a revision number to distinguish an oversight-fix release. To err is human, so let's thrive for fault tolerance. -- Dirk Eddelbuttel http://qed.econ.queensu.ca/~edd
Re: file naming convention for debian package files (was: Re: dselect FTP method ...)
We should require a revision number for Debian packages. Imagine someone forgets to remove -g in the Makefile and doesn't strip the executable, or some other oversight happens. You need a revision number to distinguish an oversight-fix release. If that were to happen to the upstream package for a non-Debian-specific package then the upstream version number would change when it was fixed. Why not for Debian-specific packages also? Looked at that way the revision number for a Debian-specific package will never change and so would be redundant. I think the absence of a revision number is a good indicator of Debian specific packages anyway. -- Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#2098: MBR control information
Package: mbr priority: required section: base maintainer: Bruce Perens [EMAIL PROTECTED] version: 1.0.0 1.0.0 Bad version: string. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Packages files now contain `size' and `md5sum'
I've updated mkpackages so that it puts the size in bytes and MD5 checksum of the files in the Packages files. I didn't put them in the same field because it seemed silly for programs and humans to have to parse the contents of a field into two essentially unrelated pieces of information, and because I couldn't think of a good field name :-). The actual Packages files are being updated as I write this. I've also changed mkpackages to leave out any empty fields that might have been in the original packages' control files. Ian.
re:dselect FTP method and dftp wrt FTP site organisation
* Someone said that we don't need to parse the version number out of the filenames. They were wrong. dftp and the dselect FTP method need to know the version numbers of packages they're thinking about downloading, so that incremental upgrades don't have to fetch all the selected packages but only the changed ones. The new 'dftp' now depends exclusively on the Packages files to determine version and revision strings. Hopefully, this will clear up the last remaining problems regarding such conflicts. I should be releasing this version next week. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Bug#2060: dpkg and depends on version again
How about = = for less/greater than or equal to Ok for strictly less/greater thani Ok for less/greater than or equal to (backwards compatibility, generates warning from dpkg-deb) Ok but an fatal error from dpkg-deb would be better than just a warning. How about no warning on package config/install operations, and a fatal error on package-build operations? Also, less importantly, how about = instead of = (or =, = and =, = as equivalent operations?).
Re: binary-alpha and binary-sparc directories
Hi, Ian Jackson wrote: As Matt Bailey suggests, I think separate Incoming directories is a better solution. I'm from the m68k section, and although it's kind of you to set up the directories for our uploads, I believe the main development of Debian/m68k is going to be done with the german ftp server at Mainz. I can't speak for the other sites here in Europe, but at least from Oldenburg (where I am) ftp.debian.org is almost unreachable (have been up to 30 hops). Also, most active developers seem to come from Europe, so they will probably agree with me. Of course this does not mean the entire tree won't get mirrored to ftp.debian.org once we have something usable. But for now I guess ftp.uni-mainz.de is the better choice for us (especially when seeing this message at ftp.debian.org all the time: 530-You are currently user 150 out of a possible 150 in your class. [..] 530 User ftp access denied. (which, btw, is funny - the count is off by one :-) It seems to me that packages will need a primary maintainer, who would be responsible for the source package, and an architecture specific maintainer for each supported binary package. One person could act in all capacities, of course, but I'd expect that at least some packages would have different maintainers for the different architectures. Ok, so what should we do? I made a few attempts at just unpacking some packages from base/ and blindly doing make -f debian.rules binaryon my Amiga, and only very few packages ran out of the box. I hope the changes will only be minor in most cases, and so it would be best for us (m68k) if we could just contact the current x86 maintainer of a package if it needs changes. That would mean digging out his name/E-Mail out of the Packages file, right? Are there any serious reasons why this cannot be done? (except, of course, for more work for the primary maintainer). The way I see this working, architecture-specific maintainers with the ability to address architecture-specific bug reports and do architecture-specific testing would feed architecture-specific fixes and patches to the primary package maintainer. Primary package maintainers having, say, a sparc would install alpha or i386 patches blindly, relying on the testing done by the alpha and i386 maintainers, and issue a package revision update. Yes. Sounds ok to me. Architecture-specific bugs for m68k will be discussed in our own debian-m68k mailing list, and if a package maintainer discovers a real problem that is architecture-independent, he would have to cooperate with the primary maintainer (where I'd like to see the corresponding person from the x86 staff to take this over). Comments? Frank
Bug#2099: slip module stops axattach
Package: ax25-util Version: 0.28.0-2.deb I tried numerous ways (including recompiling) to get axattach to load but each time it returned with the error message SIOCSIFHWADDR: Invalid argument When I removed the slip module from /etc/modules, I was then able to load axattach without errors. However, I then have no slip module. I am using Debian 0.93, kernel version 1.2.13 #4 and libc 4.6.27. -- Michael Harnois ([EMAIL PROTECTED]) No Organization Whatsoever
