Re: Release management and package announcements
Date: Wed, 1 Nov 95 22:05 GMT
From: Ian Jackson <[EMAIL PROTECTED]>
Bruce Perens writes ("Re: debian-1.0 "):
> [EMAIL PROTECTED] said:
> > it might create problems for the mirrors.
>
> I think that while it is in its current state, 1.0 should not be where
> mirrors will find it unless they are explicitly looking for it. That
> means put it under private/project or something. We can have a few
> designated mirror sites for it in various places, but we certainly
> don't need as many as are currently mirroring 0.93R6 .
I disagree. I think that 1.0 should be created immediately as a copy
of 0.93R6, and put into public view.
1.0 is going to be our bleeding edge release, and we want adventurous
people to come and test it and report the bugs. This will help us
find the integration problems &c before we have the whole user
community jumping on us. It'll also make it much easier when we want
to release it - we can just repoint a few symlinks, rather than upset
all the mirrors again.
I agree with Ian--putting the debian-1.0 tree under private makes it
difficult for it to double as our bleeding edge a.out distribution.
(If we had a separate a.out bleeding edge tree, I'd agree with Bruce.
I'm not sure what we've decided to do about it.)
Re: ELF conversion
I moved these first few parts to the beginning to get them out of the way since they're really side issues. > > I suppose this explains why > > dpkg doesn't squawk at me when I temporarily downgrade ld.so for > > testing when I know the elf-* packages explciitly require a > > semi-current version. > > I think your dependencies must say something other than what you think > they say, or possibly you're running dpkg with the `allow breaking of > depending packages' flag. dselect sets this flag by default, because > otherwise certain kinds of changes to package arrangements would be > impossible. Here are two entries from my /var/lib/dpkg/status file. I can switch back and forth between ldso-1.6.7 and ldso-1.7.10 without any warnings from dpkg by simply running 'dpkg -i filename'. What am I missing? Package: ldso Essential: yes Status: install ok installed Priority: required Section: base Maintainer: David Engel <[EMAIL PROTECTED]> Version: 1.7.10 Revision: 1 Conffiles: /etc/ld.so.conf bcdcb23c5d5fb460cee2ce315ef7bd32 Description: The Linux dynamic linker, library and utilities. The dynamic linker provides the user-level support for loading and linking DLL and ELF shared libraries. It is required by any program that uses shared libraries, which is just about all of them. Package: elf-libc Status: install ok installed Maintainer: David Engel <[EMAIL PROTECTED]> Version: 5.2.7 Revision: 1 Depends: ldso (>1.7.4-1) Conflicts: elf-gcc (2.7.0-1), elf-gcc (2.6.3-1) Description: The Linux C library version 5 (ELF). > > > Yuk. Why can't we use a sensible location, such as /usr/lib/a.out/* > > > (and /usr/bin/a.out/* if we need it) ? See what the FSSTND has to say > > > about things that think they need a directory right under /usr. > > > > Because $prefix/i486-linuxaout is the standard directory where the GNU > > development tools expect to find a.out files on an ELF system. > > Then the GNU development tools are broken, surely ? I don't think so. With ELF now being the default, a.out is considered a cross-environment. Why should the GNU tools handle it any differently from other cross-environments? > > I > > don't know if the FSSTND has even addressed this yet, but I'm > > confident they would sanction it, at least as a short term solution > > during the transition. > > The transition to a.out is not a short term thing. I still have > libraries on my system that date from my initial installation 3 years > ago; I do not want to have to live with a horrible /usr/i486-linuxaout > directory for what may turn out to be the best part of a decade ! > > I think that making assertions about what the FSSTND group would and > would not sanction is probably unwise. Surely, we've got a few FSSTND participants besides you lurking here. Dan Quinlan, are you out there? > > > `Depends' lines won't stop you replacing an earlier version of a > > > package whose dependencies were satisfied with a newer one shose > > > dependencies aren't. > > > > What! Are you telling me that dependencies aren't checked when > > already installed packages are replaced? > > You have to think about *which* dependencies are checked. Say that > foo 2.0 and bar 2.0 are both installed, and bar 2.0 depends on foo 2.0 > or later. > > Now, if I ask to install foo 1.0, dpkg will complain that this would > break bar, and would either (depending on the flags) deconfigure bar > before replacing foo in the hope that a more suitable combination of > foo and bar will turn up later, or refuse to install the older foo. OK, this is more or less what I would expect. > However, if I try to install bar 3.0, which depends on foo 3.0, dpkg > will replace the existing bar - thinking that foo 3.0 must be on its > way at some point (dselect would have been complaining if foo 3.0 ^ > weren't available at all) - and then fail to configure bar if foo 3.0 > wasn't installed by the end of the run. > > This is fine if bar isn't a critical package, without which none of > the installation tools will work. Usually the user will just do an > installation/upgrade run, and if all the files are there everything > will just work, regardless of the order (say) they inserted the > floppies. If some files are missing they'll discover the problem and > have to get them before the installation/upgrade can be completed. I don't agree that this is a safe assumption, but I can see where it is desirable (maybe even necessary) to have dselect work efficiently when installing a large number of packages. > > I'm sorry, but this not only seems plainly wrong, but can be very > > dangerous as well. I thought the whole point of having dependencies > > was so that users had to install in the proper order. How do you > > expect them to know what order to do things when order is required? > > Word of mouth? > > With respect to ordering - there are other purposes - the point of
Bug#1792: vipw, vigr missing
Package: miscutils? Version: 1.3-2 There should be vipw and vigr scripts for editing /etc/passwd and /etc/group. This is so that it is easy for the sysadmin to do the locking necessary to ensure that updates do not get lost. Ian.
upgrade and name change
I just looked around a bit on my box via "dpkg -l" and saw that I had archie, xarchieR6 dvips, dvipsk fvwm, fvwmR6 ghostview, ghostviewR6 xdvi, xdvik xpm, xpmR6 installed. That is really quite some avoidable clutter. Not that I am in favour of creping featurism---but could we find a means of declaring in the control file that the installion of foobar should delete foobarpre? What I can think of as a quick hack is the "Conflicts:" field but this still forces the sysadmin the do it by hand. Better would be something along the lines of a field "Replaces:" with values as for the "Depends:" field. Then dvipsk-5.58f-3, to pick one example, could say "Replaces: dvips (<5.58f-2)" and my copy of dvips-5.58f-2 would have been taken away automatically by dpkg. Comments? -- [EMAIL PROTECTED] http://qed.econ.queensu.ca/~edd
Re: Release management and package announcements
> > > > Agreed. I don't think the location should be decided by individual > > > > package maintainers, though they will be free to suggest a location. > > > > > > The Section field from the control file can be used for this. > > > > If the SECTION field is not going to reliably contain the section name > > where the package is placed, it should be eliminated. > > The (optional) Section information has to be there so that when a > package is installed but the user doesn't download a new Packages file > they still see the package in the right place in dselect. I guess that's my point. If the xyz.deb says "SECTION: devel" because that's where the maintainer wants it, but Ian M. decides to place the package in the text section, the user will be told "Section: devel" if he says "dpkg --status xyz.deb", and dselect will show it as either devel or text depending on whether or not the user has downloaded the Packages file. Seems more confusing than helpful to me.
Re: 1.0 issues: Packaging (esp. source)
J. H. M. Dassen writes:
> [Ian Jackson writes:]
> > 7. Unpacking a source package should not require one to execute parts
> > of it (ie, source packages should contain only data, not code used
> > during the extraction). This is important for security reasons.
>
> If you don't trust the packaging parts, why should you trust the
> claim of unmodified source?
Supposing I don't trust anything. How am I to examine the source
package ? For example, I might like to unpack it and do a diff
against a source tree I have checked more thoroughly.
It is unacceptable to create a data format for source packages that
requires the user to trust the creator of the source package with
their account just to see what's inside it.
(Shell archives have this problem, and it has long been bemoaned.)
Putting arbitrary-execution facilities into data formats may seem like
a really neat idea, but look where it got Microsoft Word, for
example.
> Taking the paranoid stance here, leads to nothing IMHO.
> For me, it would be enough to know that a certain package indeed came
> from a known maintainer (e.g. the PGP way), and have a known developer
> do an eyeball check of a first time maintainer's code.
> I have more trust in "common sense" than in a complex paranoid
> scheme.
But, don't you see that what you're advocating is precisely the use of
a complex paranoid scheme instead of common sense ?
If I have a packaging format that I can extract using a standard tool
that I know doesn't `execute' the contents of the archive then common
sense says that I'm not putting much more at risk than the target
directory of the unpack.
I shouldn't need to get into verifying the authenticity of packages
and using PGP keys and what not just to *unpack* an archive !
Likewise, I shouldn't need to drag half a dozen people into my trust
envelope just to look at a pile of source code.
I'm therefore very strongly opposed to any scheme that involves
putting shell scripts or other kinds of arbitrary program into package
archives.
Inventing a proprietery language with operations like `untar this' and
`ungzip this' and `apply this patch' would not be a problem, if you
were a little careful when you designed it, but I there seems to be
quite a bit of resistance to a format that requires a special tool to
manipulate it (and I'd be inclined to agree with that).
> Ian, please take a look at Red Hat's packaging scheme.
I have read several pieces of documentation about it, but none of them
were particularly enlightening. (I even have a paper copy of the Red
Hat manual, though it's a little old now - Red Hat kindly sent me a
free copy because of my work on the Linux FAQ.)
Perhaps I've been reading the wrong bits. Unfortunately my CD-ROM
drive is broken at the moment so I can't get the Red Hat source
package documentation off the CD-ROM they sent me.
Andrew D. Fernandes writes ("Re: Source packages"):
> [ regarding Bruce's proposal, which includes, amongst other things,
> a Debianisation patch which he called DELTA. ]
>
> I like this, but perhaps there should be two DELTA files, or one DELTA
> file with the patch program taking arguments... remember some patches
> will be debian-specific-platform-independent, while other patches
> will be debian-independent-platform-specific. We *do* hope to get
> debian ready for alphas and powerpcs some time in the far
> future... :-)
I don't think this is the job of a special patch in the source
archive. The same unpacked source tree should build on all
architectures.
If the package needs special actions for some architectures then the
debian.rules should deal with it.
Maintaining several different patches would become quite difficult, I
think: every time you edited the source you'd have to wonder which
patch you wanted your edits to go into.
Bill Mitchell writes ("Re: Debian for Linux/{non-i386} / source packaging"):
> If we concede that the upstream sources might be unpacked and then
> repacked without modification, it's not a big step to say that they're
> not repacked into a vanilla .tar.gz file but instead into some
> other format -- probably a . archive which contains the
> upstream sources as a .tar.gz file, debianizing diffs as a .diff.gz
> file, and probably some other items as well. So, we don't have
> to have an "other" file.
Right. If we make a single big archive (probably a tar), then we can
provide a tool to unpack it debianised or undebianised and to build
newer versioons, &c, but people without the tool will still be able
to manipulate the file.
Bill Mitchell writes ("Re: Source packages"):
> We operated successfully for some time as a benevelolent dictatorship.
> Ian M. has been dictator, with a rarely-used power to rule by decree.
> On a question like this, there's usually been some period of discussion,
> followed either near-consensus and dissenters throwing it the towel.
> cases where consensus didn't come out of discussion have sometimes
> been decided by decree.
>
> Lately, we
Bug#1791: dosemu troubles
Package: dosemu
Version: 0.60.3-0
Michael E Deisher writes, replying to a private mail of mine
Michael> I hope you don't mind me entering your comments (and my additional
Michael> comments) as another debian bug report.
Maybe we should have kept it private for an iteration or two to keep the
noise/signal ratio low. Oh well..
Michael> Same here. Quicken is really the only dos app I'm interested in
Michael> and it's dead-dog slow under xdos. I haven't tried playing with
Michael> the "hogthreshold". That might help, though.
Quicken's speed is now _very_ acceptable on the VC after once I chose
"rawkeyboard on" for "keyboard" in /etc/dosemu.conf. Still terrible under xdos.
Dirk> using dos on the console and with TERM=linux, I have weird problems
Dirk> with the keyboard. Cursor keys sometimes work, sometimes they
Dirk> don't. Activating numlock helps.
This is now settled. Was due to "rawkeyboard off"
Michael> Strange. I have not experienced this one. My problems on VCs
Michael> are the following:
Michael>
Michael> o no cursor o when I switch back to a running X session, the X
Michael> session dies and xdm starts another, which dies, etc., etc.
Hm, fine here with a nonameS3-805 video card.
Dirk> #serial { mouse com 1 device /dev/mouse }
Dirk> #mouse { logitech internaldriver }
Dirk> #serial { com 4 device /dev/modem }
Michael> That's strange. James just told me something about needing to
Michael> comment these out, too. I didn't realize that it was required to
Michael> get xdos to work (I thought he was talking about running on the
Michael> VC). On my system xdos works, even when I have a mouse enabled.
I don't have to comment them out or in. For xdos, they are irrelevant. For
dos under a VC, I need serial { mouse com 1 device /dev/mouse }
--
[EMAIL PROTECTED] http://qed.econ.queensu.ca/~edd
Re: ELF conversion (was Re: 1.0 issues: FSSTND compliance & preparation for a.out abolishment)
David Engel writes: > > > This elf-available bit is too klugy for me. Why can't we just use > > > dpkg's standard dependency checking? Isn't that what it's there for? > > > > `Depends' lines won't stop you replacing an earlier version of a > > package whose dependencies were satisfied with a newer one shose > > dependencies aren't. > > What! Are you telling me that dependencies aren't checked when > already installed packages are replaced? You have to think about *which* dependencies are checked. Say that foo 2.0 and bar 2.0 are both installed, and bar 2.0 depends on foo 2.0 or later. Now, if I ask to install foo 1.0, dpkg will complain that this would break bar, and would either (depending on the flags) deconfigure bar before replacing foo in the hope that a more suitable combination of foo and bar will turn up later, or refuse to install the older foo. However, if I try to install bar 3.0, which depends on foo 3.0, dpkg will replace the existing bar - thinking that foo 3.0 must be on its way at some point (dselect would have been complaining if foo 3.0 weren't available at all) - and then fail to configure bar if foo 3.0 wasn't installed by the end of the run. This is fine if bar isn't a critical package, without which none of the installation tools will work. Usually the user will just do an installation/upgrade run, and if all the files are there everything will just work, regardless of the order (say) they inserted the floppies. If some files are missing they'll discover the problem and have to get them before the installation/upgrade can be completed. > I suppose this explains why > dpkg doesn't squawk at me when I temporarily downgrade ld.so for > testing when I know the elf-* packages explciitly require a > semi-current version. I think your dependencies must say something other than what you think they say, or possibly you're running dpkg with the `allow breaking of depending packages' flag. dselect sets this flag by default, because otherwise certain kinds of changes to package arrangements would be impossible. > > This is necessary so that you can install or upgrade your system in > > any order. However, what we need to do here is to enforce an order. > > I'm sorry, but this not only seems plainly wrong, but can be very > dangerous as well. I thought the whole point of having dependencies > was so that users had to install in the proper order. How do you > expect them to know what order to do things when order is required? > Word of mouth? With respect to ordering - there are other purposes - the point of the dependency scheme is to ensure that the user (FTP site, whatever) can feed the packages to dpkg in any order, and dpkg will figure out which order to do the *configuration*. dpkg doesn't usually force packages to be *unpacked* in a particular order, because this is too hard for the user and unnecessary anyway. However, here (with base packages) we have an exception, because a broken base package will mean that the installation/upgrade will fall over because of the missing pieces before the missing pieces are processed. The way I'm proposing that we solve this problem is to require the user to do *only this* upgrade in a particular order. The way I'm proposing to enforce this is to have the packages' preinst scripts do a check that will cause the installation/replacement to abort if the requirement isn't satisfied. The way I'm proposing to tell the users about it is to tell them in the usual way: announcements to mailing lists and newsgroups, error messages, documentation, &c. > > > Next, we build a new release of libc that moves everything under /usr > > > to /usr/i486-linuxaout. This is the standard directory to put a.out > > > stuff in after switching to ELF. > > > > Yuk. Why can't we use a sensible location, such as /usr/lib/a.out/* > > (and /usr/bin/a.out/* if we need it) ? See what the FSSTND has to say > > about things that think they need a directory right under /usr. > > Because $prefix/i486-linuxaout is the standard directory where the GNU > development tools expect to find a.out files on an ELF system. Then the GNU development tools are broken, surely ? The default location ($prefix) for most of the GNU tools is /usr/local/*, but we quite rightly override that. Why can't we override their library placements, &c, to look more sensible ? > I > don't know if the FSSTND has even addressed this yet, but I'm > confident they would sanction it, at least as a short term solution > during the transition. The transition to a.out is not a short term thing. I still have libraries on my system that date from my initial installation 3 years ago; I do not want to have to live with a horrible /usr/i486-linuxaout directory for what may turn out to be the best part of a decade ! I think that making assertions about what the FSSTND group would and would not sanction is probably unwise. David Engel writes: > > However, more directly to the point of movin
Re: Release management and package announcements
Bill Mitchell writes ("Re: Release management and package announcements"):
> Ian Jackson <[EMAIL PROTECTED]> said:
> > >Somehow the FTP site maintainer's programs also need to know which
> > >section (subdirectory) the files should go in. I suggest that this
> > >information be provided by the `overrides' file on the FTP site, which
> > >is already used by the npdpkg program which generates the Packages
> > >files.
> > >
> > > Agreed. I don't think the location should be decided by individual
> > > package maintainers, though they will be free to suggest a location.
> >
> > The Section field from the control file can be used for this.
>
> I agree also that this should be decided centrally, but disagree about
> using the SECTION field for a maintainer's recommendations. If we
> do that, "dpkg --info" and "dpkg --status" will give misleading
> information to users.
>
> If the SECTION field is not going to reliably contain the section name
> where the package is placed, it should be eliminated.
The (optional) Section information has to be there so that when a
package is installed but the user doesn't download a new Packages file
they still see the package in the right place in dselect.
Information from the Packages file(s) will take precedence, if there
is any, in dselect. I could arrange for dpkg --status to use the
Packages file(s)' info if available, but I think that would be more
misleading.
Ian.
Re: Release management and package announcements
J. H. M. Dassen writes ("Re: Release management and package announcements"):
>[Ian Murdock writes:]
> >From: Ian Jackson <[EMAIL PROTECTED]>
> >
> >I think we should start with an a.out 1.0 tree. This will give us a
> >bleeding edge tree straight away, and we can then use our incremental
> >upgrade mechanisms to make the 1.0 tree move towards ELF.
> >
> > Okay--I'll agree with this. Are there any major objections?
>
> No. As long as the library moves, and the move to ELF as the default
> binary format for development get high priority, thus enabling the
> developers to make their move to ELF ASAP.
I think this is the best way to get people to move to ELF: let them do
it gradually, and with a way back out if it turns out to be a problem.
(This has been one of the major problems with the Linux ELF move
generally - there doesn't appear to be any easy way for most peoplt to
back out.)
This way we can get all the developers using ELF tools and producing
ELF packages ASAP.
Bruce Perens writes ("Re: debian-1.0 "):
> [EMAIL PROTECTED] said:
> > it might create problems for the mirrors.
>
> I think that while it is in its current state, 1.0 should not be where
> mirrors will find it unless they are explicitly looking for it. That
> means put it under private/project or something. We can have a few designated
> mirror sites for it in various places, but we certainly don't need as many
> as are currently mirroring 0.93R6 .
I disagree. I think that 1.0 should be created immediately as a copy
of 0.93R6, and put into public view.
1.0 is going to be our bleeding edge release, and we want adventurous
people to come and test it and report the bugs. This will help us
find the integration problems &c before we have the whole user
community jumping on us. It'll also make it much easier when we want
to release it - we can just repoint a few symlinks, rather than upset
all the mirrors again.
Ian.
Bug#1788: dosemu depends on xbaseR6
On Wed, 1 Nov 95 16:25 EST, [EMAIL PROTECTED] said: > I bet you still have an X11 release from the > pre-virtual-package-name area. Here I get Time to upgrade X on my machine. > For xlockmore, I have written Depends: xbaseR6 | X11R6 so that it > can cope with both settings. Good idea. --Mike
Bug#1791: dosemu troubles
Package: dosemu
Version: 0.60.3-0
Hi Dirk,
I hope you don't mind me entering your comments (and my additional
comments) as another debian bug report. Hopefully, documenting these
problems will prevent a lot of redundant bug reports.
On Wed, 1 Nov 95 16:14 EST, [EMAIL PROTECTED] said:
> Hi Mike
> sorry to bother but I am fighting dosemu to no avail.
> using xdos, I get the following error in the rxvt from which I start xdos
> ERROR: video error(0x3 page>7: 43)
> xdos works but is awfully slow (eg in Quicken it takes a second until the
> cursor responds to pressing the cursor keys)
Same here. Quicken is really the only dos app I'm interested in and
it's dead-dog slow under xdos. I haven't tried playing with the
"hogthreshold". That might help, though.
> using dos on the console and with TERM=linux, I have weird problems
> with the keyboard. Cursor keys sometimes work, sometimes they
> don't. Activating numlock helps.
Strange. I have not experienced this one. My problems on VCs are the
following:
o no cursor
o when I switch back to a running X session, the X session dies and
xdm starts another, which dies, etc., etc.
> on the console, I have a very hard time to set the mouse up. It's
> an old logitech 3button that I used for years. If I remember
> corrrecly, I used it dosemu 0.52 with no problems. I tried the
> internal driver that I use under X11, the logitech driver I used
> for years and a new logitech driver I just grabbed from Simtel.
There are some mouse drivers on tsx-11 under the dosemu directory.
You might try those, too.
> Thanks for providing the Debian package and I hope you don't mind me
> bombarding you with these unsollicited questions.
I'm pretty stressed with school so don't expect too much from me. :-/
:-)
> #serial { mouse com 1 device /dev/mouse } <-- I tried various combinations
> #mouse { logitech internaldriver } <-- of these settings, xdos
> #serial { com 4 device /dev/modem }<-- works these commented out
That's strange. James just told me something about needing to comment
these out, too. I didn't realize that it was required to get xdos to
work (I thought he was talking about running on the VC). On my system
xdos works, even when I have a mouse enabled. The fact that
performance is so hardware-dependent sure makes supporting dosemu an
interesting job! :-/
I'm cc'ing this to James. Hopefully, the additional information will
help.
--Mike
PS: James, the above comments all apply to the dosemu 0.60.3 package I
compiled for Debian.
fvwm version 2
In the reasonably near future fvwm version 2 will be released (ie, within the next few weeks, I am told). fvwm 2 has a radically different ~/.fvwmrc format, such that everyone will need to modify theirs before being able to even use fvwm2. The fvwm2 distribution will come with a shell script that does a simple-minded conversion from your old ~/.fvwmrc to the new style. Recognising the difficulty in moving over, the default way of building fvwm results in an fvwm2 binary, and the new rc file as ~/.fvwm2rc. The system-wide directory is also differently named. This is in a bid to make the new & old versions co-exist happily. I'd like people's opinions: should I package up fvwm2 as 'just an upgrade' to the fvwm package - or should I make it a _new_ package, fvwm2, allowing both to co-exist on a Debian system ? Personally, I think a new package is the way to go. Comments ? Austin
Bug#1788: dosemu depends on xbaseR6
Michael E Deisher writes: Michael> On Wed, 1 Nov 95 12:30 EST, [EMAIL PROTECTED] Michael> said: Michael> Strange. It installs fine on my system. Anyway, I'll upload a Michael> new, fixed package soon. I bet you still have an X11 release from the pre-virtual-package-name area. Here I get [EMAIL PROTECTED]:~> dpkg -s xbase Package: xbase Status: deinstall ok installed Priority: optional Section: x11 Maintainer: Ian Murdock <[EMAIL PROTECTED]> Version: 3.1.2 Revision: 2 Provides: X11R6 Depends: xlib Recommends: xstd, xmono | xserver <...> For xlockmore, I have written Depends: xbaseR6 | X11R6 so that it can cope with both settings. -- [EMAIL PROTECTED] http://qed.econ.queensu.ca/~edd
Re: ELF conversion (was Re: 1.0 issues: FSSTND compliance & preparation for a.out abolishment)
In article <[EMAIL PROTECTED]>, Bill Mitchell <[EMAIL PROTECTED]> wrote: [...] > >However, more directly to the point of moving elfward, I like Ian's >suggestion about a elf-available(8) test during preinst of elf-dependent >(elfish?) packages. It seems clean, simple, and effective to me. And if the script were called 'elf-system', then the standard error message would be quite convenient: elf-system: not found :) Austin
Bug#1790: latex2rtf can't find fonts.cfg
Package: latex2rtf Version: 1.1-0 This command line: latex2rtf file.tex > file.rtf yields this error message: latex2rtf: ERROR: cannot open file 'fonts.cfg' even when fonts.cfg is in the "right" place: bash# ls -l /usr/lib/latex2rtf total 8 -rw-r--r-- 1 root root 3491 Nov 1 14:23 direct.cfg -rw-r--r-- 1 root root 1201 Nov 1 14:23 fonts.cfg -rw-r--r-- 1 root root 1349 Nov 1 14:23 ignore.cfg This is probably a bug only in the sense that it doesn't force the new user to do the right thing, whatever that is. Susan Kleinmann [EMAIL PROTECTED] ii dpkg 1.0.5 0Package maintenance system for Debian GNU/Linux ii source 1.2.13 5Linux kernel source. ii base0.93.6 10 Debian Base System Miscellaneous Files ===
Re: ELF conversion (was Re: 1.0 issues: FSSTND compliance & preparation for a.out abolishment)
> However, more directly to the point of moving elfward, I like Ian's > suggestion about a elf-available(8) test during preinst of elf-dependent > (elfish?) packages. It seems clean, simple, and effective to me. Perhaps, but just for this one, single, isolated case. I think you are focusing too much on the change of binary formats (a.out to ELF). Don't forget that there is a fundamentally, much bigger change going on as well (libc-4.x to libc-5.x). I hope libc-6.x and X11R7 are still a long ways away, but they will happen eventually. Why can't we plan ahead now so that we can make these types of transitions easier in the future? Surely we can do better than the xpkgR5/xpkgR6 mess we had a while back. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Bug#1788: dosemu depends on xbaseR6
On Wed, 1 Nov 95 12:30 EST, [EMAIL PROTECTED] said: > miles:/debian/private/project/Incoming [root] # dpkg -i dosemu-0.60.3-0.deb > Selecting previously deselected package dosemu. > (Reading database ... 16206 files and directories currently installed.) > Unpacking dosemu (from dosemu-0.60.3-0.deb) ... > dpkg: dependency problems prevent configuration of dosemu: > dosemu depends on xbaseR6; however: > Package xbaseR6 is not installed. > ^^^ > This is an obsolete package name, please see > /debian/project/standards/virtual-package-names-list.text Strange. It installs fine on my system. Anyway, I'll upload a new, fixed package soon. --Mike
Re: debian-1.0
[EMAIL PROTECTED] said: > it might create problems for the mirrors. I think that while it is in its current state, 1.0 should not be where mirrors will find it unless they are explicitly looking for it. That means put it under private/project or something. We can have a few designated mirror sites for it in various places, but we certainly don't need as many as are currently mirroring 0.93R6 . Thanks Bruce -- See Pixar's "Toy Story", at a theater near you starting November 22. "Toy Story" Soundtrack - Available now at a record shop near you!
Re: ELF conversion (was Re: 1.0 issues: FSSTND compliance & preparation for a.out abolishment)
> > This elf-available bit is too klugy for me. Why can't we just use > > dpkg's standard dependency checking? Isn't that what it's there for? > > `Depends' lines won't stop you replacing an earlier version of a > package whose dependencies were satisfied with a newer one shose > dependencies aren't. What! Are you telling me that dependencies aren't checked when already installed packages are replaced? I suppose this explains why dpkg doesn't squawk at me when I temporarily downgrade ld.so for testing when I know the elf-* packages explciitly require a semi-current version. > This is necessary so that you can install or upgrade your system in > any order. However, what we need to do here is to enforce an order. I'm sorry, but this not only seems plainly wrong, but can be very dangerous as well. I thought the whole point of having dependencies was so that users had to install in the proper order. How do you expect them to know what order to do things when order is required? Word of mouth? > > Next, we build a new release of libc that moves everything under /usr > > to /usr/i486-linuxaout. This is the standard directory to put a.out > > stuff in after switching to ELF. > > Yuk. Why can't we use a sensible location, such as /usr/lib/a.out/* > (and /usr/bin/a.out/* if we need it) ? See what the FSSTND has to say > about things that think they need a directory right under /usr. Because $prefix/i486-linuxaout is the standard directory where the GNU development tools expect to find a.out files on an ELF system. I don't know if the FSSTND has even addressed this yet, but I'm confident they would sanction it, at least as a short term solution during the transition. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
debian-1.0
Should I physically copy everything from debian-0.93 to debian-1.0, or should I use symbolic links when possible to save disk space? I know it isn't a problem on ftp.debian.org, but it might create problems for the mirrors.
Bug#1789: time zone files not right
Package: timezone Version: 7.8-1 It looks like something's wrong with the timezone files. I started poking around when I noticed that my time was daylight savings time. I could have sworn that it was set right yesterday (I remember setting a battery powered clock by my computer -- this clock is set at the right time today, but my computer is an hour ahead). When I looked in /etc/localtime, it was a file -- not a soft link. I don't know if this is something I did, but it makes it difficult for me to determine precisely which time zone I had set (I deleted the file and moved in a soft link to EST5EDT -- which I presume is the proper zone file -- but this didn't fix the problem). Perhaps I need to reboot my system (or maybe log out or log back in) to have a new zone file take effect -- however, this was not obvious from browsing any of the manual pages that I've gone over today. Anyways, I started running zdump on the files in /usr/lib/zoneinfo, and noticed something odd -- when I was in the zoneinfo/US directory, all of the files in the US directory are GMT. Then, I popped back to the zoneinfo directory and did a zdump on all files using find -- this time they came out correct. Furthermore, there appears to be a complete duplicate set of zone files under /usr/lib/zoneinfo/right/ -- though I've not analyzed this very closely. Finally, on a hunch, I copied the EST file name to a different name (foo), zdump also reported this as a GMT file. Since this investigation, I believe I've found my problem (my DOS clock is not set to GMT, so I'm using `clock -a` in /etc/init.d/boot -- but I'll report that as a separate bug). Here's the bugs, as I understand them: (0) zdump is in /usr/sbin -- though you don't need to be root to find it useful. (1) either zdump is broken or the zoneinfo files are broken -- they depend on the file name rather than file contents to determine their time zone. This makes /etc/localtime rather useless, because it conceals the file name. -- Raul
more on time zones
I just sent a bug report to debian-bugs stating that I was going to submit a bug report on /sbin/clock for the miscutils package. I've not received an ack on that bug report, and might not check my mail again till tomorrow. This is just a note that I'm not going to submit a miscutils bug report. I'll probably eventually want to append a similar note to the bug report that I've just submitted, but that may take a while. [explanation: I don't know that /sbin/clock is ignoring information from /etc/localtime if the information in /etc/localtime is inaccurate.] -- Raul
Re: Debian for Linux/{non-i386} / source packaging
[EMAIL PROTECTED] said: > The DELTA file is described by Bruce as containing patch input. I'm > thinking it'd be better to have it contain a script to debianize the > sources. The patch input itself (and perhaps multiple patch inputs > for the multiple upstream sources) could be contained internally in > that file as one or more in "here files". The user, then, wouldn't > need to (mis?)apply the patches manually. I intended to have the utility that extracted the source package invoke patch automaticaly with the DELTA file as input. If you need an arbitrarily complicated "patch" run, you can have the extraction script do that instead of having the DELTA component be a script as well. If you want DELTA to be a no-op, make it empty. Bruce -- See Pixar's "Toy Story", at a theater near you starting November 22. "Toy Story" Soundtrack - Available now at a record shop near you!
Bug#1788: dosemu depends on xbaseR6
PACKAGE: dosemu VERSION: 0.60.3 PACKAGE_REVISION: 0 MAINTAINER: Mike Deisher <[EMAIL PROTECTED]> miles:/debian/private/project/Incoming [root] # dpkg -i dosemu-0.60.3-0.deb Selecting previously deselected package dosemu. (Reading database ... 16206 files and directories currently installed.) Unpacking dosemu (from dosemu-0.60.3-0.deb) ... dpkg: dependency problems prevent configuration of dosemu: dosemu depends on xbaseR6; however: Package xbaseR6 is not installed. ^^^ This is an obsolete package name, please see /debian/project/standards/virtual-package-names-list.text -- [EMAIL PROTECTED] http://qed.econ.queensu.ca/~edd
Papersizes
Nils, I'm sending this to Debian Devel, as mail bounced when I sent this to you at [EMAIL PROTECTED] ... Nils, Sounds like a huge improvement over the old shell script. Can you send me a copy, or should I wait to grab it from the new TeX packages? As far as the paper sizes are concerned, they are simply those defined, or understood, by ghostscript. You should be abe to find them in the a2gs man page, or in one of the ghostscript config files - can't remember which one. On another topic, do you know much PostScript? I seem to remember that there is a command for getting the file handle of the programme being interpreted, which will give STDIN if it is STDIN. This should help fix a longstanding bug in a2gs. On the other hand, I should really just bite the bullet and package up genscript. I'm sorry I can't be of more help - my Debian box is at home, and I'm not! Cheers, Kenny. -- | <[EMAIL PROTECTED]> "http://www.glg.ed.ac.uk/~kenny"; Try Linux! | | Portuguese/English/French Translations/Teaching by Native Portuguese | | <[EMAIL PROTECTED]> "http://www.glg.ed.ac.uk/~kenny/helena"; | --PAA21726.815068098/haymarket.ed.ac.uk--
Re: Source packages
> Also, I get the impression (since you mentioned you have permission to > include things on your CD-ROMs that other vendors do not) you have had > more experience with dealing with authors who have distribution > restrictions --- do you think distributing original source as separate > files might have helped or hindered negotiation of permission to > distribute? I don't think it made much of a difference. > I guess the question is whether debian is a democracy, and if not, who's > dictator? We're going to have to set up some sort of organization to operate the Debian project. I haven't had much time to work on that this week because I'm working on CD-ROM mastering. Thanks Bruce
Re: Source packages
Michael Alan Dorman <[EMAIL PROTECTED]> > Bill Mitchell pointed out that if we use totally 100% un-modified > extra-virgin upstream sources, debian-driven updates to debian source > packages become much smaller, since we're just changing the delta. [...] You're giving me credit for thinking further into the implications of this than I did. However, now that you montion it, this is an argument against Bruce's proposed new source package format. It begins to look like the DELTA file in Bruce's proposal (which I've suggested should be a debianizing script rather than raw patch input to be manually applied) should be a separate file.. The source package, in a format looking like Bruce's but without the DELTA file, would produce upstream (but possibly Linuxized?) sources for a particular upstream version of the package. Running the debianizing script for a particular debian version would then produce that version's debianizied sources. If the user kept the source package around, he'd just need to retrieve the DELTA file for the next version. re-extract sources, and run the new DELTA script. Also, debian package maintainers would only need to upload the updated DELTA script for package upgrades once the source package had been uploaded once. > I guess the question is whether debian is a democracy, and if not, who's > dictator? We operated successfully for some time as a benevelolent dictatorship. Ian M. has been dictator, with a rarely-used power to rule by decree. On a question like this, there's usually been some period of discussion, followed either near-consensus and dissenters throwing it the towel. cases where consensus didn't come out of discussion have sometimes been decided by decree. Lately, we seem to have a troika (Ian M., Bruce P., Ian J.), with firm and sometimes conflicting pronouncements by individual troika members.
Re: ELF conversion (was Re: 1.0 issues: FSSTND compliance & preparation for a.out abolishment)
Ian Jackson <[EMAIL PROTECTED]> said: > `Depends' lines won't stop you replacing an earlier version of a > package whose dependencies were satisfied with a newer one shose > dependencies aren't. > > This is necessary so that you can install or upgrade your system in > any order. However, what we need to do here is to enforce an order. Could this be enforced by having the package conflict with versions of itself earlier than some specified version? If dpkg doesn't support this now, it seems as if supporting it would address this. The downside for users is that they might find themselves in this situation, remove the conflicting older package so they could install the newer one, then find that they couldn't install the newer one until they satisfied its dependencies, leaving them with a desired package uninstalled until they straigntened this out. This might be a serious problem for users with bad (or no) connectivity. However, more directly to the point of moving elfward, I like Ian's suggestion about a elf-available(8) test during preinst of elf-dependent (elfish?) packages. It seems clean, simple, and effective to me.
Returned mail: User unknown (fwd)
> > > >- Transcript of session follows - > > 550 ac.netg.se... User unknown > > > > Hi Andres, > > > > Found a little typo in the description. > > > > PACKAGE: bison > > MAINTAINER: Anders Chrigstrom <[EMAIL PROTECTED]> > > VERSION: A2.5 > > PACKAGE_REVISION: 0 > > Diff original description and corrected description > > 5c5 > > < and non-free software (unlike the one origianaly distributed with > > --- > > > and non-free software (unlike the one originally distributed with > > -- > > Erick [EMAIL PROTECTED] +31-10-4635142 > > Department of General Surgery (Intensive Care) University Hospital > > Rotterdam NL > > > Anyone knows where to reach Anders? > > -- > Erick [EMAIL PROTECTED] +31-10-4635142 > Department of General Surgery (Intensive Care) University Hospital Rotterdam > NL > -- Erick [EMAIL PROTECTED] +31-10-4635142 Department of General Surgery (Intensive Care) University Hospital Rotterdam NL
Re: Release management and package announcements
Ian Jackson <[EMAIL PROTECTED]> said: > >Somehow the FTP site maintainer's programs also need to know which > >section (subdirectory) the files should go in. I suggest that this > >information be provided by the `overrides' file on the FTP site, which > >is already used by the npdpkg program which generates the Packages > >files. > > > > Agreed. I don't think the location should be decided by individual > > package maintainers, though they will be free to suggest a location. > > The Section field from the control file can be used for this. I agree also that this should be decided centrally, but disagree about using the SECTION field for a maintainer's recommendations. If we do that, "dpkg --info" and "dpkg --status" will give misleading information to users. If the SECTION field is not going to reliably contain the section name where the package is placed, it should be eliminated.
Re: ELF conversion (was Re: 1.0 issues: FSSTND compliance & preparation for a.out abolishment)
From: [EMAIL PROTECTED] (David Engel) Date: Tue, 31 Oct 1995 14:14:27 -0600 (CST) Some people have suggested that the stuff in /lib be moved to /lib/a.out or similar. This shouldn't be necessary as the ELF stuff that goes in here should coexist. Ah, yes. Of course. libc.so.4 and libc.so.5 will be able to coexist.
Re: Release management and package announcements
>From: Ian Jackson <[EMAIL PROTECTED]>
>
>Ian Murdock writes ("Re: Release management and package announcements"):
>> Are we going to start with an a.out 1.0 and migrate to an ELF 1.0?
>> If so, I'd agree that this is what we should do (and what I'll do
>> if we all think this is the best option).
>
>I think we should start with an a.out 1.0 tree. This will give us a
>bleeding edge tree straight away, and we can then use our incremental
>upgrade mechanisms to make the 1.0 tree move towards ELF.
>
> Okay--I'll agree with this. Are there any major objections?
No. As long as the library moves, and the move to ELF as the default
binary format for development get high priority, thus enabling the
developers to make their move to ELF ASAP.
Great!
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: Release management and package announcements
Date: Wed, 1 Nov 95 13:16 GMT
From: Ian Jackson <[EMAIL PROTECTED]>
Ian Murdock writes ("Re: Release management and package announcements"):
> Are we going to start with an a.out 1.0 and migrate to an ELF 1.0?
> If so, I'd agree that this is what we should do (and what I'll do
> if we all think this is the best option).
I think we should start with an a.out 1.0 tree. This will give us a
bleeding edge tree straight away, and we can then use our incremental
upgrade mechanisms to make the 1.0 tree move towards ELF.
Okay--I'll agree with this. Are there any major objections?
Re: Source packages
On Tue, 31 Oct 1995, Bruce Perens wrote: > The second file is an executable script that performs the actual > extraction, creating a subdirectory under the current directory > and moving files as necessary. Its name is EXTRACT, and it must have > execute permissions set. Bill Mitchell pointed out that if we use totally 100% un-modified extra-virgin upstream sources, debian-driven updates to debian source packages become much smaller, since we're just changing the delta. Do you have any thoughts on this? Also, I get the impression (since you mentioned you have permission to include things on your CD-ROMs that other vendors do not) you have had more experience with dealing with authors who have distribution restrictions --- do you think distributing original source as separate files might have helped or hindered negotiation of permission to distribute? > This would be quite trivial to implement. It has the advantage that it > contains > the unmodifed upstream source (not even its name has to be changed) and the > diff file in a single unit, and can be extracted on any system that contains > tar and gunzip. I think this sounds fine, though I am curious about your reactions to the above. I guess the question is whether debian is a democracy, and if not, who's dictator? Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Bug#1785: Default font.
Juho A. Vuori writes ("Bug#1785: Default font."):
> Package: kbd
> Version: 0.90-3
>
> This is not an actual bug, but in my opinion, it's not wise to have
> default8x16 as the default font in /etc/rc.boot/console. Shouldn't it
> rather be iso01.f16 in unix world?
As I have reported several times before, /etc/rc.boot/console should
*not* install *any* font by default.
The effect of doing so is to screw up the console on some systems (eg
mine). There is no need for it.
Ian.
Re: ELF conversion (was Re: 1.0 issues: FSSTND compliance & preparation for a.out abolishment)
David Engel writes ("Re: ELF conversion (was Re: 1.0 issues: FSSTND compliance
& preparation for a.out abolishment)"):
> > 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.
>
> This elf-available bit is too klugy for me. Why can't we just use
> dpkg's standard dependency checking? Isn't that what it's there for?
`Depends' lines won't stop you replacing an earlier version of a
package whose dependencies were satisfied with a newer one shose
dependencies aren't.
This is necessary so that you can install or upgrade your system in
any order. However, what we need to do here is to enforce an order.
I could provide a new dpkg control file field to do this, but there
are a number of problems with that, and since only the base packages
are affected by this problem it seems better to deal with the problem
in the way I suggested above.
> > 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.
>
> Renaming packages seems rather error prone to me. How would it be
> done? This sure complicates our upgrade procedure -- first upgrade to
> this set of packages, then run this command or install this special
> package which renames things, finally install these other packages,
> etc. Ick!
Renaming packages involves releasing a package with the new name which
conflicts with the old one. There is a bug to do with conffile
handling in this situation, but (a) I'm going to fix it and (b) it
won't affect the libc, because it doesn't have any conffiles.
The user will have to be told to upgrade their libc's first (using `dpkg
--install libc-aout.deb libc-elf.deb' or whatever), and can then use
dselect for the rest of the operation.
> Next, we build a new release of libc that moves everything under /usr
> to /usr/i486-linuxaout. This is the standard directory to put a.out
> stuff in after switching to ELF.
Yuk. Why can't we use a sensible location, such as /usr/lib/a.out/*
(and /usr/bin/a.out/* if we need it) ? See what the FSSTND has to say
about things that think they need a directory right under /usr.
> Some people have suggested that the
> stuff in /lib be moved to /lib/a.out or similar. This shouldn't be
> necessary as the ELF stuff that goes in here should coexist.
Good.
> Then, build a new release of elf-libc with everything moved from
> /usr/i486-linuxelf to /lib and /usr. This new package should be named
> libc5 (note not libc) and have appropriate conflicts lines with older,
> pre-ELF versions of the libc package.
>
> Finally, so we don't repeat the same mistakes again, any new packages
> built using libc5 should explicitly list it in their dependencies.
Right.
Ian.
Bug#1787: forwarded message from Cron Daemon
Package: wu-ftpd Version: 2.4-13 The attached message shows wu-ftpd producing unnecessary output during cron.monthly. Ian. --- start of forwarded message (RFC 934 encapsulation) --- Return-Path: Received: by chiark.chu.cam.ac.uk id m0tAX23-0002YUC (Debian /\oo/\ Smail3.1.29.1 #29.33); Wed, 1 Nov 95 06:52 GMT Message-Id: <[EMAIL PROTECTED]> X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: From: root (Cron Daemon) To: root Subject: Cron <[EMAIL PROTECTED]> run-parts /etc/cron.monthly Date: Wed, 1 Nov 95 06:52 GMT Rotating wu-ftpd server logfile: Rotated `/var/log/xferlog' at Wed Nov 1 06:52:24 GMT 1995. --- end ---
Re: Release management and package announcements
Ian Murdock writes ("Re: Release management and package announcements"):
> Are we going to start with an a.out 1.0 and migrate to an ELF 1.0?
> If so, I'd agree that this is what we should do (and what I'll do
> if we all think this is the best option).
I think we should start with an a.out 1.0 tree. This will give us a
bleeding edge tree straight away, and we can then use our incremental
upgrade mechanisms to make the 1.0 tree move towards ELF.
> If we're going to start with an ELF 1.0 (which is what I assumed we
> would do), we need to replace the current gcc, libc, etc. packages
> with ELF versions as the default and make the necessary changes to
> the existing packages to turn them into a.out compatability packages
> (i.e., move the libraries in /lib to /lib/a.out or whatever). After
> we do that, we need to build an ELF base system, so developers will
> be able to install a completely ELF system and start rebuilding the
> packages they are responsible for.
I think this is a higher-risk strategy. Remember how difficult it was
in the days when 0.93 wasn't useable, and many of the developers were
still `cross-developing' ?
>Somehow the FTP site maintainer's programs also need to know which
>section (subdirectory) the files should go in. I suggest that this
>information be provided by the `overrides' file on the FTP site, which
>is already used by the npdpkg program which generates the Packages
>files.
>
> Agreed. I don't think the location should be decided by individual
> package maintainers, though they will be free to suggest a location.
The Section field from the control file can be used for this.
Ian.
Bug#1786: Revision number not updated
Package: perl Version: 5.001-5 [As noted by Brian White:] Perl 5.001-5 has 'revision: 4' in the control file. -- LOGIC The principle governing human intellection. Its nature may be deduced from examining the two following propositions, both of which are held by human beings to be true and often by the same people: 'I can't so you mustn't', and 'I can but you mustn't.' - The Hipcrime Vocab by Chad C. Mulligan
Bug#1695:
reassign
Re: Draft: Hints for contributing to Debian GNU/Linux (fwd)
In article <[EMAIL PROTECTED]> Erick Branderhorst <[EMAIL PROTECTED]> writes: > > > [del] > > > 5. Beyond packages > > > [del] > > > > > > (eb) > > > * Option for automatic installation for local html documentation? > > > This needs to be discussed first I think. > > > (eb) > > > > I don't understand this, please explain it. > > > Well perhaps dpkg can be given an option to create html documentation if > packages are shipped with html documentation or sources where html docu > can be created from. I.e. an optional documentation format. At this moment > only /usr/doc, /usr/doc/examples, info and manpages are provided for > documentat > ion. We might add html too for documentation purposes. To make it clearer > I run debian on a stand alone machine. This seems to be a good idea. I think you should discuss this at debian-devel. (This may involve adding fields to the package description, so the discussion should be public.) > An other thing might be a default html document where all browser will > look at. Right now some postinst scripts ask what the default start page > should be (default http://www.debian.org/). This works great if you have > netaccess. If you don't you are lost when you start for example lynx or so, > at least you have to wait until it times out. If we can provide one default > html doc with some decent links to debian related stuff this problem would > be solved. This was already discussed at debian-devel, although I don't know what the result was. I will ask the www-client maintainers about it. Sven -- Sven Rudolph ([EMAIL PROTECTED]); WWW : http://www.sax.de/~sr1/ -- Erick [EMAIL PROTECTED] +31-10-4635142 Department of General Surgery (Intensive Care) University Hospital Rotterdam NL
Re: Debian for Linux/{non-i386} / source packaging
On Tue, 31 Oct 1995, James A. Robinson wrote: > Now hold on a second there! What about packages put together from > multiple sources? Say MH with Linux patchs? I don't want to deal > with writing something that will be able to intelligently do the > patchs needed and then make the source. That's a wrinkle I don't think we've yet considered. It seems like Bruce's proposal could cover this, though. The EXTRACT file could create a subdirectory and extract the multiple upstream source packages into separate subdirectories under that. The third file (unnamed by Bruce) could contain a tarfile of several tarfiles, each containing a single upstream source package. The DELTA file is described by Bruce as containing patch input. I'm thinking it'd be better to have it contain a script to debianize the sources. The patch input itself (and perhaps multiple patch inputs for the multiple upstream sources) could be contained internally in that file as one or more in "here files". The user, then, wouldn't need to (mis?)apply the patches manually. I haven't looked at MH, but it sounds like there'd be an upstream source subdirectory for MH, and one for the linux patches. The DELTA script, then, would apply the linux patches to the MH sources, then apply its internal debianizing patches to what resulted from that. If pristine upstream sources are needed by a user, they'd still be there, and would be easy to extract manually.
Forwarded mail....
A day in the life of the FTP server 2.6 gigabytes today... Also if you can not tell from these logs/averages. I have added win3/win95/winnt mirrors of simtel to the list of offerings. :) Instead of running painful virtual ftp servers I have opted for a more generic way of doing things. I therefore have merged everything into one archive. --Matt -- Forwarded message -- Date: Wed, 1 Nov 1995 00:00:16 -0500 From: Charlie Root <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] TOTALS FOR SUMMARY PERIOD Tue Oct 31 1995 TO Wed Nov 1 1995 Files Transmitted During Summary Period 10746 Bytes Transmitted During Summary Period2693654107 Systems Using Archives 0 Average Files Transmitted Daily 5373 Average Bytes Transmitted Daily1346827054 Daily Transmission Statistics Number OfNumber ofAveragePercent Of Percent Of DateFiles Sent Bytes Sent Xmit Rate Files Sent Bytes Sent --- -- --- -- -- -- Tue Oct 31 1995 10744 26924056324.6 KB/s 99.98 99.95 Wed Nov 1 1995 2 1248475 21.5 KB/s 0.020.05 Total Transfers from each Archive Section (By bytes) Percent Of Archive Section Files Sent Bytes Sent Files Sent Bytes Sent - -- --- -- -- /debian/debian-0.93/binar 4358 132898467740.55 49.34 /debian 315 327619271 2.93 12.16 /debian/debian-0.93/sourc 1775 32593395516.52 12.10 /debian/debian-0.93/disks160 162247177 1.49 6.02 /pub/ftp.freebsd.org/2.0.376 138621980 3.50 5.15 /pub/ftp.freebsd.org/2.1.373 102539231 3.47 3.81 /debian/debian-0.93 11084991819 1.02 3.16 /debian/project/experimen 8233616424 0.76 1.25 /debian/private/project 11829488149 1.10 1.09 /debian/non-free/source 9424310716 0.87 0.90 /debian/non-free/binary 14924259829 1.39 0.90 /pub/ftp.netscape.com/2.0 3120385171 0.29 0.76 /debian/debian-bugs/html12391574389711.53 0.58 /debian/debian-bugs/text 94711354895 8.81 0.42 /debian/non-free 210896631 0.02 0.40 /pub/ftp.cs.helsinki.fi/. 1 7337907 0.01 0.27 /debian/tools 52 6177341 0.48 0.23 /debian/kernel40 6148273 0.37 0.23 /debian/debian-0.93/ms-do 79 5742120 0.74 0.21 /pub/ftp.cs.helsinki.fi/v 2 4704595 0.02 0.17 /pub/ftp.cs.helsinki.fi/v 8 4628521 0.07 0.17 /pub/ftp.cs.helsinki.fi 10 2586925 0.09 0.10 /debian/contrib/source 6 1778799 0.06 0.07 /pub1/win95/virus 2 1594455 0.02 0.06 /pub1/nt/shells4 1497262 0.04 0.06 /pub1/win3/scrsaver4 1415203 0.04 0.05 /pub/ftp.netscape.com/pub 3 1313951 0.03 0.05 /pub1/win3/graphics3 936402 0.03 0.03 /pub1/win3/winsock 4 892784 0.04 0.03 /debian/project/standards 58 721894 0.54 0.03 /pub/ftp.freebsd.org/tool 3 572717 0.03 0.02 /pub1/win3/cdrom 2 551501 0.02 0.02 /usr/bin 3 544768 0.03 0.02 /debian/contrib/binary75 479248 0.70 0.02 /debian/non-free/ms-dos 61 442670 0.57 0.02 /pub1/win3/news3 378427 0.03 0.01 /debian/project/software 2 377578 0.02 0.01 /pub1/win3/diskutil2 377398 0.02 0.01 /pub1/win3/capture 2 365590 0.02 0.01 /pub1/win3/tex 3 279278 0.03 0.01 /debian/contrib/tools 8 251936 0.07 0.01 /pub1/win3/desktop 2 163231 0.02 0.01 /usr/bin/site-exec 2 98304 0.02 0.00 /pub1/win3 3 90054 0.03 0.00 /debian/info 19 64316 0.18 0.00 /debian/contrib/ms-dos67 44955 0.62 0.00 /debian/doc 14 27552 0.13 0.00 Index/Informational Files 13 10250 0.12 0.00 /pub1/win3/internet27702 0.02 0.00 /pub1/nt 27021 0.02 0.00 /pub/ftp.freebsd.org/docs 1
