Re: package uploading probs
On Mon, 30 Oct 1995, Ian Jackson wrote: > > chiark.chu.cam.ac.uk:/debian/private/Incoming > > Matt, can you mirror this somewhere ? /private/project/incoming-uk And should there be a doom subdirectory there? Just curious... Matt
Re: package uploading probs
Hallo Matthew Bailey! }> directory across some sites with good connectivity and use rdist(1) to keep them }> in sync? Major mirror sites might be good canditates for this. }> }I would probably suggest just mirror as a program to keep them up to date. }If there is a SINGLE site then this would not be a problem. Are you sure that mirror is a good idea? How are files on a european mirror deleted? I won't make sense retrieving them again every hour. }I would mirror them into a directory called }private/project/incoming-europe I have talked about this before but I }beleive that no one was able to come up with a site. }Let me know the URL and I will begin an hourly mirror of it, asuming that }is OK with the rest of Devel. I think it's a good idea. There are some debian mirrors in europe I know of: ftp.leidenuniv.nl and somewhere at *.uni-dresden.de. If you decide to so, It would be a good idea if that machine gets an alias as ftp.europe.debian.org, so that it can be easily found and used. Regards, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / +49-441-777884 * Login&Passwd: nuucp * Index: ~/ls-lR.gz / / Germany.Net ist vergleichbar mit einem Telefon/ / ohne Waehlscheibe und Klingel... -- Lutz Donnerhacke / 30.10.95: Oldenburger Linux-Stammtisch, ab 20h im DaCapo
Re: package uploading probs
Just finished with my 1st cup of coffee today :) Nice to see there's some discussion on this topic underway. Martin Schulze writes: >Hallo Matthew Bailey! > >}> directory across some sites with good connectivity and use rdist(1) to keep >them >}> in sync? Major mirror sites might be good canditates for this. >}> >}I would probably suggest just mirror as a program to keep them up to date. >}If there is a SINGLE site then this would not be a problem. > >Are you sure that mirror is a good idea? How are files on a european >mirror deleted? I won't make sense retrieving them again every hour. Junk your mirror program, if it refetches files - at the very least rewrite it :) In my original post I proposed sort of a distributed package upload directory for developers. Despite the directory name, some of you guys 'n gals fetch packages from ftp.debian.org's incoming directory as soon as they are announced. At least that's what I conclude when seeing bug reports for packages not yet in public view. OTOH in general I don't like any polling approaches - maybe that's a personal preference. Why should you add to network traffic only to find out there's nothing to be mirrored? Are there any security problems when using rdist on mutually trusted sites? I'm using it only on a LAN where I'm the only user I wouldn't trust :) Sorry Matthew, I know you don't like rdist. Is there any compelling reason for your dislike? > >}I would mirror them into a directory called >}private/project/incoming-europe I have talked about this before but I >}beleive that no one was able to come up with a site. > >}Let me know the URL and I will begin an hourly mirror of it, asuming that >}is OK with the rest of Devel. > >I think it's a good idea. There are some debian mirrors in europe I >know of: ftp.leidenuniv.nl and somewhere at *.uni-dresden.de. ftp.uni-paderborn.de wasn't in debian.mirrors last time I checked. >If you decide to so, It would be a good idea if that machine gets an >alias as ftp.europe.debian.org, so that it can be easily found and >used. That probably isn't a good idea. Since the primary purpose is a regional upload directory, it will be used only by a limited set of people who should know what they are doing. Regs -- Siggy
man pages for accouting package
I am planning on adapting the information in the /usr/doc/accounting texinfo page to a series of `man' pages in the acct package. Some might argue that this is redundant and therefore wastes disk space and introduces the chance for errors. Others might argue that this is a useful complement to the remainder of the man page documentation. If you have a strong preference, please express it. Susan Kleinmann [EMAIL PROTECTED]
Re: man pages for accouting package
> I am planning on adapting the information in the /usr/doc/accounting > texinfo page to a series of `man' pages in the acct package. > Some might argue that this is redundant and therefore wastes disk > space and introduces the chance for errors. Others might argue that > this is a useful complement to the remainder of the man page > documentation. If you have a strong preference, please express it. > Susan Kleinmann > [EMAIL PROTECTED] On the contrary - IMO there should be a manual page for every command that Debian has, great idea :-) ...Karl -- | PO Box 828 Office: (09)316-3036 Fax: (09)381-3909 |OWER INTERNET SERVICES Canning Bridge After Hours: 015-779-828 WA, 6153 Sales Support: [EMAIL PROTECTED] Internet Service Providers and Networking Solutions
Bug#1780: mh looks in the wrong place for 'more'
Package: mh Version: 6.8.3-2 The 0.93R6 MH mail user interface package causes it to be impossible to read any mail, since the default moreproc is '/usr/bin/more', and the current Debian release appears to put more in '/bin/more' instead. You end up with errors like: [EMAIL PROTECTED]:~: show (Message inbox:386) show: unable to exec /usr/bin/more: No such file or directory [EMAIL PROTECTED]:~: The fix is probably to change the file conf/MH in the source tree, whacking the line options SYS5 MORE='"/usr/bin/more"' RENAME SYS5DIR UNISTD SVR4 MIME to point to the right location for more. It is possible to work around this defect by specifying an explicit path for more in the user's .mh_profile: moreproc: /bin/more But this shouldn't be necessary. Bdale
Bug#1780: mh looks in the wrong place for 'more'
Bdale Garbee writes: >It is possible to work around this defect by specifying an explicit path for >more in the user's .mh_profile: > > moreproc: /bin/more Dunno much about MH but your might consider the following for a workaround: If there is a global config file for mh, you may put it there for the benefit of all users on your system. If there is no such file, make /usr/bin/more a symbolic link to /bin/more until the bug gets fixed. -- Siggy
Bug#1782: no_root_squash fails with nfs
Package: netstd Version: 1.20 When mounting an nfs volume with no_root_squash set things worked fine for a while then my root uid seemed to get squashed for some reason. Unmounting and mounting again seemed to solve the problem. I'm not quite sure what caused this. [kryten:/home/andrew] more /etc/exports # /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). / starbug (rw,no_root_squash) Andrew -- Dehydration - 34%, Recollection of previous evening - 2%, embarrassment factor - 91%. Advise repair schedule:- off line for 36 hours, re-boot startup disk, and replace head - wow, what a night! -- Kryten in Red Dwarf `The Last Day' Andrew Howell [EMAIL PROTECTED] Perth, Western Australia [EMAIL PROTECTED]
Re: package uploading probs
Matthew Bailey writes ("Re: package uploading probs "):
> On Mon, 30 Oct 1995, Ian Jackson wrote:
> > chiark.chu.cam.ac.uk:/debian/private/Incoming
> > Matt, can you mirror this somewhere ?
>
> /private/project/incoming-uk
> And should there be a doom subdirectory there?
Oops, that was a mistake. I meant to use and say
chiark.chu.cam.ac.uk:/pub/debian/private/Incoming
(note `pub').
I've moved the directory to that location, and added a symlink.
There is a doom subdirectory at the same level as the debian
subdirectory, under /pub.
Ian.
Some Issues wrt/ 1.0
Dear developers, I'll be listing a couple of issues that I think are relevant for the development of the 1.0 release. I'll expand them in separate messages. I'll try not to take sides in debates that'll probably be reopened; I'm merely trying to provide a framework for the discussion. Move to ELF: - move to ncurses - FSSTND compliance and perparation for a.out abolishment General: - source packageing format Ray -- Cyberspace, a final frontier. These are the voyages of my messages, on a lightspeed mission to explore strange new systems and to boldly go where no data has gone before.
1.0 issues: FSSTND compliance & preparation for a.out abolishment
Subject: 1.0 issues: FSSTND compliance & preparation for a.out abolishment Short Description - The default Linux binary format is to move to ELF. Most of the libraries and other support is already debianized, but uses non-standard locations. In the long term, we want users to be able to remove the a.out libraries, binutils etc, once all their binaries are ELF. Considerations -- - Eventually, we don't want users bothered with two sets of libaries. - Currently, the ELF libraries are in non-FSSTND compliant locations: under /usr/i486-linuxelf. This means that they cannot be used for packages like sysvinit, which are needed before /usr is available (/usr may be on a separate partition, see FSSTND). Proposal - Make new packages for a.out libraries, binutils, gcc, efence that use a non-default location: /lib-a.out and /usr/i486-linux-a.out - Make new ELF packages for libraries, binutils, gcc, efence that use the FSSTND locations /lib and /usr, and which drop the -elf suffix. - Use 'Conflicts:' to prevent trouble. This makes the ELF packages (and therefore, 1.0) FSSTND compliant again, and makes compliation default to ELF. To be solved - The dpkg database does not distinguish between ELF and a.out binaries, so it cannot be used to decide if a.out-library removal is possible. Furthermore, users may have "unregistred" binaries e.g. in /usr/local. The best solution is probably to have a script using 'find' and 'file' to determine if the a.out libraries can be removed. Ray -- Cyberspace, a final frontier. These are the voyages of my messages, on a lightspeed mission to explore strange new systems and to boldly go where no data has gone before.
1.0 issues: Packaging (esp. source)
Subject: 1.0 issues: Packaging (esp. source)
Short Description
-
There appears to be concensus among the developers that the current
source packaging system, which has debianized source packages,
should be replaced by a system that uses unmodified source.
Desirable goals for source packaging
- Upstream sources should be used unmodified.
- It should be as useful as reasonably possible for non-debian
users and non-debian distribution maintainers.
- The source packaging system should support non-intel architectures.
Links
-
- http://www.redhat.com/alpha/alpha.html Red Hat's Linux on Alpha page.
- http://www.redhat.com/rpm.htmlRed Hat's packaging system.
- mailto:[EMAIL PROTECTED] The Bogus developers.
- http://www.cl.cam.ac.uk/users/iwj10/linux-faq/section1.html#cpu
ports to other architectures.
- http://www.freebsd.org/, http://www.netbsd.org/ The freeware BSDs.
- http://www.wi.LeidenUniv.nl/Beheer/texi/standards_toc.html
the GNU coding standards
- vger mailing lists: linux-{admin,fsf,qag,standards}
Proposal
- Distribute wholly unmodified source
- Have the source extracted and patches by a 'debianizer' script.
This could be akin to perl5-style patches (a sh script combined with
the patch).
- First apply platform-independant patches
- Then apply platform-dependant patches
- Then apply debian-specific patches (optional, but on by default).
- Provide a standardized compilation front end (a la debian.rules)
as part of the non-debian-specific patches.
- Develop this (PCKGSTND?) in discussion with other Linux distributions,
the non-intel porters, the FSF and perhaps the BSD distributions.
Issues to be resolved / TO DO
-
- Tools for making a debianizer (anybody got a better name?)
- Update the packaging guidelines
- Take the pros but not the cons from current packaging schemes
- How to do architecture-dependance stuff with the control, {pre,post}{inst,rm}
files?
Ray
--
Cyberspace, a final frontier. These are the voyages of my messages,
on a lightspeed mission to explore strange new systems and to boldly go
where no data has gone before.
1.0 issues: move to ncurses
Description --- The Powers That Be (most importantly, the linux libraries maintainers) have decided to drop both termcap and curses support (they are not present in the newer ELF libc's for example). Both of these libraries are replaced by ncurses, which AFAIK uses the same interface. Links - http://sable.ox.ac.uk/~jo95004/elf.html The ELF web page. Includes H.J. Lu's statement about dropping support. http://www.ccil.org/~esr/ncurses.html (Eric S. Raymond's ncurses page; Eric is a co-maintainer of ncurses). Required action --- The move to ncurses involves changes source packages to use ncurses per default, and fall back to curses or termcap when ncurses is not available. This is probably best done in coordination with the upstream maintainer(s). Ray -- Cyberspace, a final frontier. These are the voyages of my messages, on a lightspeed mission to explore strange new systems and to boldly go where no data has gone before.
Re: Distribution
Hallo Ian Jackson! }So, what we're left with, if you agree with my release strategy, is: } } released -> debian-0.93 } debian-0.93/binary [ bugfixes and urgent releases only ] } source } ms-dos } Packages -> binary/Packages } disks So bugfixes et cetera still go into a released release (eh published release). So we run into the great slackware problem that there are tons of version 2.2 (as an example). I don't agree to that. What about the following: released -> debian-0.93 debian-0.93/binary source ms-dos Packages -> binary/Packages disks updates/binary [ bugfixes and urgent releases only ] source ms-dos Packages -> binary/Packages disks Then it's a static Debian GNU/Linux 0.93R6 for say half a year. Only some updates will go into the updates directory. Users who download 0.93R6 once won't have to check for everything if they want to have a problemless release. They can look at the updates dir. And cdrom vendors don't have the problem that their just pressed cd is outdated just by publishing it. What about 1.0? Ian Murdock told us that it will be fully ELF, so we all have to creat ELF packages? } doc/ [ Shouldn't we merge doc/, info/ and some } info/of project/ ? ] yes! }Does this seem good to people ? Partially Gruesse, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / +49-441-777884 * Login&Passwd: nuucp * Index: ~/ls-lR.gz / / Germany.Net ist vergleichbar mit einem Telefon/ / ohne Waehlscheibe und Klingel... -- Lutz Donnerhacke / 30.10.95: Oldenburger Linux-Stammtisch, ab 20h im DaCapo
Re: Distribution
[EMAIL PROTECTED] (Martin Schulze) said: > So bugfixes et cetera still go into a released release (eh published > release). So we run into the great slackware problem that there are > tons of version 2.2 (as an example). > > I don't agree to that. [...] Wait a sec. I think we have a definition or a perception problem here. What is debian 0.93R6? 1. Just the install disk set? 2. The install disk set plus a frozen set of base packages? 3. The install disk set plus a frozen complete distribution? I think it's #1, or maybe (I don't think so) #2, but not #3. > [...] What about the following: > > released -> debian-0.93 > debian-0.93/binary > source > ms-dos > Packages -> binary/Packages > disks > [...] But the implications of this directory structure don't support my opinion. Joey adds to this: > updates/binary [ bugfixes and urgent releases only ] > [...] > Then it's a static Debian GNU/Linux 0.93R6 for say half a year. Only > some updates will go into the updates directory. Users who download > 0.93R6 once won't have to check for everything if they want to have a > problemless release. They can look at the updates dir. And cdrom > vendors don't have the problem that their just pressed cd is outdated > just by publishing it. "bugfixes and urgent releases only" (?!?!?!?!?!) Where's the value of incremental upgradeability in this? If a spiffy new upstream release of some package comes down the pipe, and is packaged up by the maintainer, it should be made available to debian users now, IMHO, not six months or so from now. I think we should adopt the attitude that the distribution packages on the ftp site are the latest and greatest. If someone presses a CD from what he finds there today he's got today's snapshot, and it might be out of date tomorrow. That's life. That said, I'm worried that we've gone through periods where the package selection available on the FTP site has transient problems. If someone presses a CDROM while these transient problems are present, he's casting the problems into stone (well, plastic) for many of the purchasers of his CDROM. If commercial CDROM vendors are going to be pressing CDROMS based on snapshots taken from our site, we ought to make a greater effort than we currently do to assure that they've got a working distribution to take a snapshot of. On reflection, if my opinion about just what is debian 0.93 is correct, the current directory structure with its implication that the package set on the ftp site belongs with the version-numbered release is unfortunate. Something like this: debian-0.93/binary/ INDEX README docs/ disks/ Packages->../a.out-packages (or perhaps not) a.out-packages/ INDEX README source/ binary/ ms-dos/ might have been better. However, it looks like such changes cause more trouble on the mirrors than it is reasonable to put them through.
Re: Draft: Hints for contributing to Debian GNU/Linux
Draft notes: * Comments that shouldn't appear in the final document are marked in the following way: ( comment -sr1) These comments usually highlight open questions. In this case I am interested in answers. (see next sentence) * Please send comments about the contents of this document via private e-mail to me (Sven Rudolph <[EMAIL PROTECTED]>). * English isn't my native language, so I am interested in suggestions regarding my style of writing. Please send these via private e-mail. * I intend to send the final document to debian-user regularly (e.g. weekly). It should be available at ftp.debian.org. I received feedback from : * Dirk.Eddelbuettel <[EMAIL PROTECTED]> * Erick Branderhorst <[EMAIL PROTECTED]> * J.H.M.Dassen <[EMAIL PROTECTED]> . $Id: contributing,v 1.2 1995/10/30 22:33:12 sr1 Exp sr1 $ Hints for contributing to Debian GNU/Linux 0. Contents (not yet done -sr1) 1. General Questions 1.1. What is Debian GNU/Linux Please read the Debian GNU/Linux FAQ. The Debian GNU/Linux WWW server is at http://www.debian.org/ , the FAQ is located at http://www.debian.org/FAQ/ . 1.2. Purpose of this document This document is intended to identify areas that need your contributions. It provides information that hopefully changes quite often, so it supplements the Debian GNU/Linux FAQ. 1.3. What do I need to know in order to become a package maintainer ? (Pointer to the documents in debian/project/standards -sr1) 1.4. Feedback Please send additions, corrections and suggestions to Sven Rudolph <[EMAIL PROTECTED]>. 2. Package that have no current maintainer Packages listed in this section are still part of Debian (unless they have too many bugs), but the maintainer had reasons to not continue maintaining it. (Remember: Debian is mainly made by volunteers who are not paid for maintaining Debian packages.) If you want to give up maintaining a package, send an e-mail to Sven Rudolph <[EMAIL PROTECTED]>. If you believe that a certain package that isn't listed here doesn't have a current maintainer anymore, send e-mail to Sven Rudolph <[EMAIL PROTECTED]>. If you intend to maintain one of the packages listed here, write ( who should do this (or wants to do this) ? -sr1). * ghostscript, gsfonts (previously maintained by Ted Hajek <[EMAIL PROTECTED]>, he got an increased non-Debian workload) * elm \ * ircii\ (Carl Streeter <[EMAIL PROTECTED]> maintained * wenglish > these packages. Where is he ? -sr1) * unzip, zip / * perl/ (J.H.M.Dassen <[EMAIL PROTECTED]> created a newer perl package, but it is declared experimental because he doesn't have the time to maintain it.) * strace (is this correct ? or is there already someone interested in it ? -sr1) 3. Packages that the maintainer wants to give away Packages listed in this section are still part of Debian, but the maintainer wants to find a new maintainer. It isn't as urgent to find a new maintainer as in the previous section. If you maintain Debian packages that you would like to get rid of, send an e-mail to Sven Rudolph <[EMAIL PROTECTED]> , then he will add this package to this section. If you intend to maintain one of the packages listed here, write the current maintainer of this package. * seyon \ (currently maintained by * mailx / Sven Rudolph <[EMAIL PROTECTED]> ) 4. Not-yet existing packages Programs listed in this section aren't yet available as Debian packages, but someone wished them. If you want to create a Debian package, send an e-mail to Alvar Bray <[EMAIL PROTECTED]> . I 4.1. Programming and development: * GNU Pascal. * UPS - the X-based debugger. Probably not worth building until we've switched to ELF. (There are Linux-specific patches around.) * checker (electric-fence is already available. Is checker better, worse or different ? -sr1) * vgrind (formats source code for printing) * Scheme->C * SCM - Scheme interpreter which will soon be the basis of the GNU extension language. * SLIB. * CLISP - Common Lisp interpreter * GCL - Common Lisp compiler (nee AKCL) and... * ECoLisp - a Common Lisp compiler that produces faster code but isn't as widely used as GCL * CLiCC - Common Lisp compiler that generates stand-alone apps (rather large ones, though) * GNAT (GNU Ada Translator) 4.2. Mail software: * BBDB (for Emacs: Big Brother Data Base, a rolodex with hooks into VM, GNUS, and RMAIL) 4.3. USENET news software: * nn. * C News (as an alternative to INN) including NOV and NNTP. * strn. 4.4. Maths packages: * Octave (the FSF's Matlab clone). * SC (the spreadsheet). (oleo is already available) * GNU calc (see the Emacs list ...). * SNNS Stuttgart Neural Network Simulator (ftp.informatik.uni-stuttgart.de) * SciLab * Yorick 4.5. CAD: * SISCAD, a CADD package. ftp://hrz-ws26.hrz.uni-kassel.de/pub/machines/LINUX/misc/siscad * Kubota Graphics Corporation's now-PD 3-D visualization system, Do
Rant (was Re: Distribution)
Bill Mitchell writes ("Re: Distribution"):
> Wait a sec. I think we have a definition or a perception problem here.
>
> What is debian 0.93R6?
> 1. Just the install disk set?
> 2. The install disk set plus a frozen set of base packages?
> 3. The install disk set plus a frozen complete distribution?
>
> I think it's #1, or maybe (I don't think so) #2, but not #3.
It doesn't have to be any of those. I keep banging away at this. Our
choices are not `complete chaos and instant update of everything'
vs. `completely frozen distribution'.
How about `Debian 0.93R6 is the current stable distribution, including
the disks, and also including any later bugfixes'.
> "bugfixes and urgent releases only" (?!?!?!?!?!)
> Where's the value of incremental upgradeability in this?
>
> If a spiffy new upstream release of some package comes down the pipe,
> and is packaged up by the maintainer, it should be made available to
> debian users now, IMHO, not six months or so from now.
If that's what you want you ought to be using the `development' tree.
That will have the latest spiffy version of everything. It'll have
more bugs, of course, and change much more rapidly.
The value of incremental upgradeability is that we can support
everyone - we can support *all of*:
- people who want to install once and then do a quarterly or
half-yearly download of an `updates' directory.
- people who get a CD-ROM every quarter or so.
- people with good connectivity who want to be on the bleeding
edge.
- people with good connectivity who want to be using a nice stable
release and upgrade it in one major shift every few months
- people who want the latest stable and well-working version of
everything.
- people who want a mixture of any of the above.
My proposal supports this better than any of the other proposals I've
seen. It certainly supports it better than any proposal involving
frozen snapshots.
> On reflection, if my opinion about just what is debian 0.93 is correct,
> the current directory structure with its implication that the package set
> on the ftp site belongs with the version-numbered release is unfortunate.
> Something like this:
>
> debian-0.93/binary/
> INDEX
> README
> docs/
> disks/
> Packages->../a.out-packages (or perhaps not)
>
> a.out-packages/
> INDEX
> README
> source/
> binary/
> ms-dos/
>
> might have been better. However, it looks like such changes cause more
> trouble on the mirrors than it is reasonable to put them through.
We need both a stable and a development tree. It doesn't make sense
to name these after a.out vs. ELF, because at some point we'll have an
all-ELF stable tree.
Martin Schulze writes ("Re: Distribution"):
> Hallo Ian Jackson!
> }So, what we're left with, if you agree with my release strategy, is:
> }
> } released -> debian-0.93
> } debian-0.93/binary [ bugfixes and urgent releases only ]
> } source
> } ms-dos
> } Packages -> binary/Packages
> } disks
>
> So bugfixes et cetera still go into a released release (eh published
> release). So we run into the great slackware problem that there are
> tons of version 2.2 (as an example).
>
> I don't agree to that.
I think you have a problem with language here. "I don't agree to
that" implies in English that you are the person making the decision
and have decided to veto what I was proposing.
This list has not always been noted for its even temper (see also
debian-private recently), and I'm currently having great difficulty
preventing my blood boiling over.
I feel *very* strongly that we *must not* have a frozen-in-stone
release. There are little or no benefits and a lot of disbenefits.
The fact that not everybody's 0.93R6 is the same doesn't matter: after
all, after people have configured their systems no two systems are
alike.
> [...]
> Then it's a static Debian GNU/Linux 0.93R6 for say half a year. Only
> some updates will go into the updates directory. Users who download
> 0.93R6 once won't have to check for everything if they want to have a
> problemless release. They can look at the updates dir.
My proposal provides an updates directory that can be used in exactly
this way. There is NO NEED to freeze the released distribution's main
tree just to provide incremental update directories too.
> And cdrom
> vendors don't have the problem that their just pressed cd is outdated
> just by publishing it.
Sod them ! I'm sorry, but why on earth should we freeze our release
on the FTP site when we don't have to, just because then we'd be
providing a better product than the CD-ROM vendors ? The fact is that
for many people an FTP'able or NFS'able distribution *is* better than
a CD-ROM, in part *because* it is more easily updated for those
people.
Ian.
ELF conversion (was Re: 1.0 issues: FSSTND compliance & preparation for a.out abolishment)
J. H. M. Dassen writes: > The default Linux binary format is to move to ELF. Most of the libraries > and other support is already debianized, but uses non-standard locations. > In the long term, we want users to be able to remove the a.out libraries, > binutils etc, once all their binaries are ELF. This is true. I think that as the dpkg maintainer I probably have a reasonably good idea of how we can go about this so as to maintain minimum problems: 1. Firstly, we make sure that all our a.out packages have a Depends line that refers to the a.out libc in some way. We're still behind on this, but it ought to be done, IMO. Certainly all the base packages need this to prevent serious accidents. 2. Secondly, we arrange that all the new base packages have code in the preinst that checks for the existence of the ELF libraries (perhaps by running /usr/bin/elf-available or something). If the libraries aren't found then the preinst returns a non-zero exit status and the upgrade aborts. Say: #!/bin/sh set -e elf-available And elf-available is an ELF version of /bin/true supplied with one of the ELF library packages. Then if elf-available is missing or something else goes wrong we get a message like /var/lib/dpkg/tmp.ci/preinst: elf-available: not found and the installation aborts. If we're feeling fancy we can write code that prints a more helpful message. 3. We do a `renaming' operation on the a.out libc package, renaming it to a.out-libc. At the same time we move the a.out libraries inside it to their non-FSSTND locations if appropriate, but we need to keep the ones currently in /lib in the root partition. Eventually this package will be removed from Required - when all the base packages are converted to ELF. 4. The ELF packages are renamed to `libc' and made to conflict with the old versions. NB that they don't conflict with the new a.out-libc package. We'll have to tell the users to upgrade the libc first, but that's inevitable, I think. Alternatively, they should be able to just run the upgrade twice, ignoring the errors the first one throws up (though it might get to the point where dpkg gives up). > - The dpkg database does not distinguish between ELF and a.out binaries, > so it cannot be used to decide if a.out-library removal is possible. It could do, if the packages used the dependency feature to indicate which library they needed. > Furthermore, users may have "unregistred" binaries e.g. in /usr/local. > The best solution is probably to have a script using 'find' and 'file' > to determine if the a.out libraries can be removed. I'm not convinced this is necessary. We should probably keep the a.out-libc package for quite a while, and most people won't want to deinstall it for ages. Ian.
Re: 1.0 issues: Packaging (esp. source)
On Mon, 30 Oct 1995, J.H.M.Dassen wrote: > [...] > Desirable goals for source packaging > > - Upstream sources should be used unmodified. >[...] > - Distribute wholly unmodified source > - Have the source extracted and patches by a 'debianizer' script. > This could be akin to perl5-style patches (a sh script combined with > the patch). > [...] Back in the eary days of the project, before binary packages and long before dpkg, I argued for distributing unmodified upstream sources and debianizing diffs. I lost that argument, but I had futzed around with a debianizing script, and I find that I still have a copy. I'll include it below. I haven't retried it because I'm busy with other things. I had also argued that the original sources should extract into -, as is usual with upstream sources, and that the debian sources should be placed in -.debian. I lost that argument too and I see that this script perpetuates that lost argument, which I still believe is not the way we should be doing this. Anyhow, here's my very old script. It might serve as a starting point. #!/bin/sh # # this shell script produces the debian source package # it requires that that the debian source be in $PACKAGE # and that the original pre-debian source be in $PACKAGE.orig # it assumes that this script is run from inside $PACKAGE # DIR=`pwd` PACKAGE=`basename $DIR` # # check for the original package # if [ ! -d ../$PACKAGE.orig ] then echo ERROR: $PACKAGE.orig not found exit 1 fi # # archive the original source package # we want the tarfile to extract it into $PACKAGE # cd ..# get up to the parent directory mv $PACKAGE $PACKAGE.temp.$$ # rename the debian package mv $PACKAGE.orig $PACKAGE# rename the original package tar --create --file $PACKAGE.tar $PACKAGE# make the tar file mv $PACKAGE $PACKAGE.orig# rename the original package mv $PACKAGE.temp.$$ $PACKAGE # rename the debian package gzip -9 --force $PACKAGE.tar # compress the tar file cd $PACKAGE # back down to the debian directory # # make and gzip the diff file # # NOTE -- to apply the diffs # 1. place the original sources in $PACKAGE # 2. place the the patch file in the parent directory # 3. invoke "patch -d $PACKAGE.diff gzip -9 --force $PACKAGE.diff# compress the diff cd $DIR # back down to the debian directory # # we're done # exit 0 I recall that I later approached this from a slightly different angle, which might be better. That was to distribute a machine-built debianizing shell script which wrapped the debianizing diffs in a script to apply them. I don't seem to have a copy of that, but it ought to be pretty trivial to do. Also, I think RedHat does something like this in their package admin tools. That's been discussed a bit in debian-devel, but I don't think anyone has taken the time to look at it.
