Re: Packages should not Conflict on the basis of duplicate functionality
As a user, I have to say that the "Provides/Conflicts" that happens with POP3 servers is annoying. I wanted to look at each of ipopd, gnu-pop3d and cucipop. I could only look at one at a time. It was ok in my case, because the machine I was using has very little pop3 traffic. But it was awkward. If I wanted to download source and recompile it, I would not be using Debian. I like the package manager. I also like the thought that goes into problems like this. I'd like to see something like this: WARNING: you already have a pop3-server installed (cucipop) starting ipopd automatically may cause problems there are cases where running several pop3-servers automatically makes sense: most of them require you to do special configuration. if you answer No to the following question, you can edit "some configuration file", then run "some reconfiguration program" to start ipopd without conflicting with the existing pop3-server. Read /usr/share/doc/ipopd/somedocfile for instructions on how to do this. do you want ipopd to start automatically? (y/N) WARNING: you already have an http-server installed (apache) starting apache-ssl automatically may cause problems there are cases where running several http-servers automatically makes sense: most of them require you to do special configuration. if you answer No to the following question, you can edit /etc/apache-ssl/httpd.conf, then run "some reconfiguration program" to start apache-ssl without conflicting with the existing http-server. Read /usr/share/doc/apache-ssl/somedocfile for instructions on how to do this. do you want apache-ssl to start automatically? (y/N) I am full aware that this doesn't solve all the problems. Some services start from init.d scripts, some from inetd. pop3 servers seem to mostly run from inetd. But someone may package one that starts from an init.d script. Sometimes, different protocols use the same port (ssh and ssh2 come to mind) In the ssh case, one solution is to enable the "ssh1 compatibility" in the sshd2 configuration. Another is to run ssh1 or ssh2 on a different port. Pretty soon, there will be two DNS servers: some people will want to run Bind as their main server, and test the new one on perhaps just one IP address. A "Provides/Conflicts" in this case would (for me) really really suck. This is a problem that each person who packages a service that listens on a port has to deal with. And more of a problem because different implementations of such a service are packaged by different people. Perhaps a general framework for dealing with the issue would help, if it left room for each packager to handle things as the package requires. The following presumes that each package that provides a service will provide a virtual package, "service-server", so that the potential conflict can be detected and dealt with, and that when such a conflict is detected, a nice long question is asked of the user, and the user answers yes or no (with no being the default). Something like: if it starts from an init.d script, have the init.d script check for the existence of some configuration file. based on the content or existence of that file, start or don't start the service, configured as appropriate. if the user answers no to the auto-start question, make sure the special file is in the state which prevents the service from starting. provide also a script in /usr/sbin to let the user turn on and off the service, and/or provide a document in /usr/share/doc/package which describes how to do it (the document should exist, whether the script does or not). if it starts from /etc/inetd, put a line into /etc/inetd which would start the service, but commented out if the service should not be started by default. in this case, the user will probably have to edit /etc/services and /etc/inetd to get the service started with no conflict. provide a document in /usr/share/doc/package which describes how to do it. (i omitted the script here because it seems to be taboo to edit /etc/services from any package except that which owns it) I'm going to look at ipopd, gnu-pop3d, cucipop, apache, apache-ssl, ssh and ssh2 to see how bad my idea is. I'll post what I find out. If a framework like this makes sense, then no package has to know about another package, and no packager has to know what another packager is doing, so long as each package and packager "does the right thing" when a potential conflict crops up. The bottom line: let the user decide. Eric Bestnet Internet Inc On Fri, 1 Oct 1999 10:28:03 +1000, Craig Sanders wrote: >On Thu, Sep 30, 1999 at 08:34:48AM -0400, Raul Miller wrote: >> On Thu, Sep 30, 1999 at 02:16:31PM +1000, Craig Sanders wrote: >> > to paraphrase: i am against messing with the current default. i am not >> > against (indeed, i am in favour of) increasing choice. >> >> There is currently no default -- it varies on a per-package basis. > >update-inetd and update-rc.d pretty much
Re: nasty slink -> potato upgrade problem
And/or make the new Perl pre-depend on the new apt, so the apt update will happen before anything else? On Sat, 11 Mar 2000, Nicolás Lichtmaier wrote: > > > Trouble ahead? > > Please run "apt-get install apt" before doing the dist-upgrade. Old apt > > don't manage well the perl transition. This will be documented in the > > Release Notes. > > Why don't we make the new perls conflict the old apt? > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup.
Re: netstd split results in loss of functionality
License problems: namely, there isn't one, and it's not clearly public domain, and nobody knows who the author is. On Mon, 13 Mar 2000, Daniel Martin wrote: > Hamish Moffatt <[EMAIL PROTECTED]> writes: > > > Hi, > > > > Why doesn't netstd depend: on all the packages it previously included? > > When upgrading to potato, tftpd functionality is lost because the new > > netstd only suggests it. And the parameters to tftpd have changed > > and the new package does not update the inetd entry. > > Speaking of which, where did netdate go? I've been wondering for a > while what happened to it. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- You mean you can only become totally invisible when nobodie's watching you?
Re: glibc-compat ???
On Thu, 23 Mar 2000, Hamish Moffatt wrote: > On Thu, Mar 23, 2000 at 02:42:26AM -0300, Taupter wrote: > > Strange. If i can remember, Slink has libc5 compatibility libs. > > Why not glibc2.0 compatibility libs for potato, as RH-based distros > > have? > > They're both libc 6.0 -- how would ld.so know which one you wanted? > Any apps which run on 6.0 and not 6.1 are broken and should be fixed. Some things changed from 2.0 to 2.1 so that non broken binaries won't work. One I know about is stat, which is now a macro instead of a function call (breaks smbsh, even if you recompile it) Some other software doesn't work either. One I know about is IBM DB2 database. I don't know why it doesn't work, it just doesn't, and of course I don't have the source. I've thought about compatibility links, but like you said, they're both libc 6.0. Overall though, there doesn't seem to be a lot of broken stuff. -- precision of expression is more important than conformance to traditional rules
Re: RBL report..
This spam issue is so political. If you're stuck with a service provider who has a crappy mail service, and/or who has your IP listed on the DUL, I'll offer a solution. I run an ISP in Canada. We offer shell accounts, on a machine running Debian Potato, for a reasonable price ($10/month, or $60/year) Then you can use SSH to tunnel mail through my server. The box is running sendmail 8.9.3 I'm pretty anal about people who try to use the shell server for DoS or theft of service (ie spam) I don't expect anyone on this list would do either. A description of our shell service can be found at http://shell.bestnet.org/ Any current Debian developer will get the service for half price on a yearly basis ($30/year) Same goes for people with sponsored packages. Email [EMAIL PROTECTED] if you're interested. As for the list spam issue: spam on the lists is annoying, but not a showstopper (yet) I think the "X-Spam" header idea is a good one. Politics aside, it allows for a simple and public examination of which of DUL, ORBS etc catch what spam on the list, without stopping any legitimate mail from getting through. I also believe that stripping Received headers is a mistake. They are useful for tracking problems, not just spam. Maybe X-Received is an option for dealing with broken mailers. Cheers! Eric -- Mathematics belongs to God -- Donald Knuth
Re: What's changed in su/bash? "bash: fork: Resource temporarily unavailable"
I just logged in on console as root, and ulimit -a reported 256 processes max. So I don't think the problem is with su. Maybe it's PAM? I wonder where this gets configured? On Thu, 30 Mar 2000, Oliver Elphick wrote: > Brian Greenfield wrote: > >On Fri, 31 Mar 2000 00:12:12 +0900, Junichi Uekawa > ><[EMAIL PROTECTED]> wrote: > > > >>In Thu, 30 Mar 2000 11:10:20 +0100, de profundis "Oliver Elphick" <[EMAIL > PROTECTED] > >x.co.uk> cum veritas scribat > > > >>and see how many processes root is running ... > > > >237! > > > >Samba running as a daemon rather than from inetd seems to > >have cured it. > > So all of a sudden, any process started through 'su root' is limited by > ulimit, which is counting all processes belonging to root, including daemons. > But a direct login to root is not limited in this way. > > Why this change? and which package changed it? > > -- > Oliver Elphick[EMAIL PROTECTED] > Isle of Wight http://www.lfix.co.uk/oliver >PGP key from public servers; key ID 32B8FAA1 > > "But the fruit of the Spirit is love, joy, peace, > patience, kindness, goodness, faithfulness, > gentleness, self control; against such there is no > law."Galatians 5:22,23 > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup.
Re: (g)mc-4.5.38-2 still broken
On Thu, 16 Sep 1999 19:54:11 +0200 (CEST), Piotr Roszatycki wrote: >No no, it isn't mc script but only function in your ~/.bash_profile or >global /etc/profile. > >I'm afraid many people have some kind of function or aliases related >to _real_ mc binary and current mc wrapper can broke it. > >BTW, >/usr/bin/mcedit is a symlink to /etc/bin/mc which is an only wrapper. >This is the reason that mcedit doesn't work already. Quite. And this has nothing to do with how much resources a bash takes up. When the bash exits, control is returned to the original directory; no matter what the bash script did. And, the idea of editing /etc/profile or whatever is to my mind really bad. The upstream source for mc has sample scripts which users can call from their own .bash_profile, .profile, etc, both for Bourne and C shells. They should be made available (they are also listed on the man page for mc) ps: the reason for not doing cd `mc -P "$@"` is given in the man page. Something to do with control-Z to suspend doesn't work unless you use the temporary file method. On Thu, 16 Sep 1999 19:54:11 +0200 (CEST), Piotr Roszatycki wrote: >On 16 Sep 1999, Philip Hands wrote: > >> Wait a second. >> >> So this mc script is an attempt to leave you in the directory you were >> in when you left mc ? >> >> Well that won't work will it? >> >> Try running this: >> >> cd /tmp; ( cd /etc; pwd ); pwd > >No no, it isn't mc script but only function in your ~/.bash_profile or >global /etc/profile. > >I'm afraid many people have some kind of function or aliases related >to _real_ mc binary and current mc wrapper can broke it. > >BTW, >/usr/bin/mcedit is a symlink to /etc/bin/mc which is an only wrapper. >This is the reason that mcedit doesn't work already. > >-- > >Piotr "Dexter" Roszatycki >mailto:[EMAIL PROTECTED] > > >-- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
