Re: binary-alpha and binary-sparc directories
Bill Mitchell writes (Re: binary-alpha and binary-sparc directories): This seems shakey -- especially if we posit that the i386 maintainer is in the U.S., the Mac maintainer in Germany, and the PowerPC maintainer in Korea. Also, the upstream source maintainer might be in Romania, and might not be be interested in picking up the Mac and PowerPC changes which our maintainers have made to his source code. The (primary) maintainer of a package is the one who maintains the *source*. They may not necessarily build the i386 binary, perhaps only the m68k or some such. A Debian source package should compile under any architecture (unless its function is inherently architecture-specific). If it doesn't it is a bug which it is the responsibility of the primary maintainer to fix. If the primary maintainer doesn't fix it we should consider the package orphaned, and then the person trying to build for another architecture can upload their source as the generic source, either officially taking over the package or just putting out an `interim' release. There's no problem, btw, with having several source versions in the FTP site. We should only delete an old source version when all the old binaries have been replaced with the new ones (this is a GPL requirement, amongst other things). Ian.
Thoughts on Replaces field (was Re: binary-alpha and binary-sparc directories)
'Ian Jackson wrote:' I think I'll have to support `Replaces' or something, so that old packages can have all their files `taken away' and disappear eventually. Here's the scenario that I hope a Replaces fiels might resolve. I'm working on the S-lang library. Both most and Midnight Commander depend on S-lang, so building a shared library makes sense (and with ELF it's easy to do!). But S-lang is under development and shared libraries aren't compatible from month-to-month (unless I don't understand some subtlety in ELF - very likely, actually). I released most-4.5.0-1 and slang-lib-0.99.23-1. But now I want to release slang-lib-0.99.24-1, but it's incompatible with slang-lib-0.99.23-1 which it should replace. Of course, most depends on slang-lib (version 0.99.23-1 ONLY). most-4.5.0-1 breaks with slang-lib-0.99.24-1. So I need to build another most with slang-lib-0.99.24-1 support. So I envision this specification for the Replaces: field: GIVEN: A, B, and C all depend on package D AND Package E replaces package D. Then When E is installed, it leaves D alone (since things still depend on D). When A, B, or C are upgraded (to versions compatible with E) they are removed from D's dependancy list. Once D's dependency list is empty, D is removed (making sure that E is intact). I think this would give the flexiblity that the S-lang example needs and that isn't presently present. If I remember correctly Ian didn't like encoding the shared library version in the package name (I'm starting to agree). But right now that is the only proposed solution to the problem that I've seen. OK, now I'm waiting for you all to tell me what details I've omitted ... BTW, I think dpkg blazes - performance-wise (especially compared to rpm which is a dog)! Well done. -- Christopher J. Fearnley|UNIX SIG Leader at PACS [EMAIL PROTECTED] (finger me!)|(Philadelphia Area Computer Society) http://www.netaxs.com/~cjf |Design Science Revolutionary ftp://ftp.netaxs.com/people/cjf|Explorer in Universe Dare to be Naive -- Bucky Fuller |Linux Advocate
Re: binary-alpha and binary-sparc directories
Raul Miller writes (Re: binary-alpha and binary-sparc directories): How about the option of a better record of what has happened? For example, currently, if multiple packages supply the same file only the most recently installed package has the files listed in it's .list file. If we have package installation time recorded, we wouldn't lose any information if (a) all packages which supplied a file had the file listed in their .list files. (b) the default behavior of dpkg would be to not remove a file till all packages with references to it were removed. This makes sense. I think I'll have to support `Replaces' or something, so that old packages can have all their files `taken away' and disappear eventually. If it's a speed issue, perhaps I should spend some time profiling dpkg? No, it's not a speed issue - it's a question of deciding what the behaviour should be and then me finding time to implement it. I've added this to the wishlist ... 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.
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.
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.
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
Re: binary-alpha and binary-sparc directories
Raul Miller wrote lately: Ian Murdock: I doubt there'll be a substantial number of architecture-neutral packages; we can either copy or link them into all of the trees. I suppose this depends on what you mean by substantial... Here's a list of packages that appear to be architecture-neutral, by cursory examination on my system. any package which needs to be compiled is of course not arch-independent. on my system here (sunos, not debian ;-)) at least the following are partially compiled: ii dvips5.58f 2TeX DVI-driver for Postscript ii fort77 1.6 1An f2c front end to make it look like a compile ii makeidx 2.12 Makeindex, a general purpose index processor ii metafont 2.71 2Metafont - TeX's font engine ii xdvi 1.8f 2A TeX DVI-previewer for X11 the following is even in the source not arch-independent: ii syslinux 1.20 0Boot disk creator. of the following i don't know (now) which files are included. some files which i call auxilary files (eg the string pool) are also arch-dependent, but they might not be included in this package. ii mflib 1.0 5Auxiliary files to run Metafont ii texlib 1.0 4Auxiliary Files to run TeX bye jjm -- Juergen Menden | Disclaimer: The opinions expressed by me, tel:+49 (89) 2051 - 2387 +---+ are (usually) not the opinions e-mail: [EMAIL PROTECTED] | of anyone else on this planet. Hi! I'm a .signature virus! Add me to your .signature and join in the fun!
Re: binary-alpha and binary-sparc directories
[This goes to debian-devel only.] Raul Miller writes: Raul It does look like dvips was superceeded by some other package, and Raul that it did originally have some executables in it. Nils switched to the upstream convention of reflecting the 'k' for Karl Berry's kpathsea in the package name. I had moaned about this weeks ago. You have to manually delete dvips after installing dvipsk, xdvi after xdvik etc. A Conflicts: in debian.control might have helped here. Or a new Replaces: field. Raul /usr/bin/fort77 is a perl script, the only other things I see in this Raul package are a man page and a copyright statement. Since I have f2c Raul on my system as a separate package, I'd guess that fort77 has also Raul been superceeded... Nope. f2c is a pain as far as the interface is concerned. fort77 is a pretty little perl beauty that gives it an f77-like interface so that you can seamlessly use Makefiles that assume you have f77. (I also linked it to f77.) [...] -- Dirk Eddelbuttel http://qed.econ.queensu.ca/~edd
dpkg Replaces: field (was Re: binary-alpha and binary-sparc directories)
'[EMAIL PROTECTED] wrote:' Raul Miller writes: Raul It does look like dvips was superceeded by some other package, and Raul that it did originally have some executables in it. Nils switched to the upstream convention of reflecting the 'k' for Karl Berry's kpathsea in the package name. I had moaned about this weeks ago. You have to manually delete dvips after installing dvipsk, xdvi after xdvik etc. A Conflicts: in debian.control might have helped here. Or a new Replaces: field. Yes, this seems to me a good idea. Conflicts involves too much administrator intervention. Ian, can we have this feature in dpkg? -- Christopher J. Fearnley|UNIX SIG Leader at PACS [EMAIL PROTECTED] (finger me!)|(Philadelphia Area Computer Society) http://www.netaxs.com/~cjf |Design Science Revolutionary ftp://ftp.netaxs.com/people/cjf|Explorer in Universe Dare to be Naive -- Bucky Fuller |Linux Advocate
Re: binary-alpha and binary-sparc directories
Juergen Menden: any package which needs to be compiled is of course not arch-independent. on my system here (sunos, not debian ;-)) at least the following are partially compiled: ii dvips5.58f 2TeX DVI-driver for Postscript ii fort77 1.6 1An f2c front end to make it look like a ii makeidx 2.12 Makeindex, a general purpose index proce ii metafont 2.71 2Metafont - TeX's font engine ii xdvi 1.8f 2A TeX DVI-previewer for X11 ... 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. /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... I think this is a bug in the debian packaging mechanisms. The current mechanism presumes that files of the same name are drop-in replacements for each other. It currently manages the archive by removing all references to a file but the most recent package to provide the file. This was conceived of as a way of managing packages which are partially provided for on the base disks. However, a better way of managing base packages is to record the partial installation of the packages and mark them with a suitable status code (for example, unpacked). Then, when they're installed for real dpkg can treat these the same as any other incomplete package installation. For the more general case of packages which inadvertently provide the same facilities, when one of the packages is removed the other may become nonfunctional. It's perfectly all-right for the most recent package to be installed to provide the files for an ambiguous case. But, the fact that another package needs the file should also be recorded. Only one package can have supplied the physical instance of the file, but the file might be included with more than one package. Or, perhaps it would be simpler for dpkg to protest and refuse to install a package if it has a file-overlap with another package? Either way, the present behavior invites errors. -- Raul
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. michaelkjohnson
Re: binary-alpha and binary-sparc directories
On Wed, 27 Dec 1995, Matthew Bailey wrote: For those out there that are interested. I will make space available for these ports, and allow each group to maintain uploads for the subtree. Please contact me if you are in need of an account for this use. Please don't do this. I'd rather that the alpha, m68k, and sparc versions be maintained just like the i386 version is maintained. (That is, contributors upload packages to an Incoming directory and I move them into the archive from there.)
Re: binary-alpha and binary-sparc directories
On Wed, 27 Dec 1995, Dominik Kubla wrote: you might as well add binary-m68k since the first Debian/68k packages are starting to appear. Okay. These packages as well as the necessary source patches are currently stored at U-Mainz: ftp.uni-mainz.de:/pub/Linux/devel/debian/dontuse/m68k/ Should I copy all of this to the new m68k directory at ftp.debian.org?
Re: binary-alpha and binary-sparc directories
Hello Ian, you might as well add binary-m68k since the first Debian/68k packages are starting to appear. These packages as well as the necessary source patches are currently stored at U-Mainz: ftp.uni-mainz.de:/pub/Linux/devel/debian/dontuse/m68k/ Curently the follwing packages are available for m68k: binutils-2.6.debgcc-aout-2.7.2.deb libgxx-2.7.1.deb gcc-2.7.2.deb gxx-2.7.2.deb ncurses-1.9.8a.deb And of course dpkg is available (only as nondebbin.tar.gz) There is already a debian-68k mailing-list in place at Pixar.com (as you might have noticed from the cc-line...) As for the Alpha stuff: i am still wrestling with the subtilities of bootstrapping Linux in an unsupported environment. Don't expect anything before mid-January ... Happy new year! Dominik BTW. Could somebody please put me on the debian-devel list? I would make it easier for me ...
Re: binary-alpha and binary-sparc directories
For those out there that are interested. I will make space available for these ports, and allow each group to maintain uploads for the subtree. Please contact me if you are in need of an account for this use. -- Matthew S. Bailey 107 Emmons Hall Central Michigan University Mt. Pleasant, MI 48858 [EMAIL PROTECTED] ... Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.)
Re: binary-alpha and binary-sparc directories
On Sat, 23 Dec 1995, Ian Murdock wrote: I've created binary-alpha and binary-sparc directories under the development tree. They're both empty at the moment, of course, but they're ready for use whenever the development teams have something to put there. (BTW, I plan to rename binary to binary-i386 as soon as we finish the planned FTP reorganization.) 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. 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? 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.
