Linux-Misc Digest #588, Volume #24               Wed, 24 May 00 18:13:03 EDT

Contents:
  Re: hisax (isdn driver module) won't load... (Byron A Jeff)
  Mutt and "word wrap" ("Frank Ekeberg H.")
  Re: Future Domain ISA scsi card recognition problem ("Art S. Kagel")
  Re: Redhat 6 install problems... (Leonard Evens)
  Re: Need ideas for university funded project for linux (Praedor Tempus)
  Re: Need ideas for university funded project for linux (Matthias Warkus)
  Re: Motif release to Open Source Community leads to Open Motif  Everywhere (phil 
hunt)
  Re: msie 5 for unix on linux (Andrew Purugganan)
  Re: Redhat 6 install problems... ("John P")
  Re: Need ideas for university funded project for linux ([EMAIL PROTECTED])
  Re: how to enter a bug report against linux? (Leslie Mikesell)
  Re: Print in Landscape orientation ([EMAIL PROTECTED])
  Re: Need ideas for university funded project for linux ([EMAIL PROTECTED])

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Byron A Jeff)
Subject: Re: hisax (isdn driver module) won't load...
Date: 24 May 2000 17:08:45 -0400

In article <[EMAIL PROTECTED]>,
Tuomas Launiainen  <[EMAIL PROTECTED]> wrote:
-I have a Terton 128i passive isdn card. I'm told they are either WInbond
-6692 or HFC PCI based, so I compiled hisax support for both in my
-kernel, hisax as module. Then I installed isdn4k and isdn4linux and ran
-"isdn setup".
-
-Then, "modprobe hisax type=35 (or 36, tried both) io=0xd400 (this is
-correct, I checked)" prints out:
-/lib/modules/2.2.14-5.0/misc/hisax.o: init_module: Device or resource
-busy
-/lib/modules/2.2.14-5.0/misc/hisax.o: insmod
-/lib/modules/2.2.14-5.0/misc/hisax.o failed
-/lib/modules/2.2.14-5.0/misc/hisax.o: insmod hisax failed
-
-and "insmod hisax type=36 (or 36) io=0xd400" prints:
-/lib/modules/2.2.14-5.0/misc/hisax.o: init_module: Device or resource
-busy
-
-What could this mean? The sound card has the same irq as the isdn card,
-but that works fine in windows and the sound card works in linux too.
-What can be done?

I'd suggest checking the output of the 'dmesg' command or your kernel
logs (located in /var/log). The Hisax driver prints status messages to the
log files and should indicate why the driver doesn't load.

BAJ

------------------------------

From: "Frank Ekeberg H." <[EMAIL PROTECTED]>
Subject: Mutt and "word wrap"
Date: Wed, 24 May 2000 13:39:38 +0000

Is there a way to have Mutt make sure that the lines of my email messages do not 
exceed 72 characters (or whatever length I choose to use)? 
I use emacs as my editor, but other users might use other editors, and I want the 
layout of all email sent from this domain to be similar. 
If not Mutt, can Sendmail check this?

thanks,
frank

------------------------------

Date: Wed, 24 May 2000 17:17:27 -0400
From: "Art S. Kagel" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Future Domain ISA scsi card recognition problem

Steve wrote:
> 
> I have an 18xx scsi card with a TMC18c30 chip set. It does seem to
> be recognised by my Mandrake 7.0 setup. Is there anything I can do
> to get this working by means of IRQ's etc?

I'm going to suggest that you get another SCSI card.  I had one of those and 
they are more trouble than they are worth, and with the ready availability 
of cheap SCSI cards out there it's just not worth the effort.  Future Domain 
is defunct, the card did large drive sector mapping in a different and 
incompatible way from just about EVERY other SCSI card on the market so if 
you do oneday have to get a new card you will not be able to use your 
drives unless you set the card up to NOT remap sectors, and performance 
is abysmal.  FWIW.

Art S. Kagel

------------------------------

From: Leonard Evens <[EMAIL PROTECTED]>
Subject: Re: Redhat 6 install problems...
Date: Wed, 24 May 2000 15:51:53 -0500

John P wrote:
> 
> I've just installed RedHat 6.2 (boxed version) and when it finished
> installing, it wouldn't write a boot disk for some reason.. I think because
> my floppy drive is actually an LS-120. I'd also selected to load LILO.
> 
> When it rebooted I got the "L01 01 01.." problem which I gather happened
> because I installed all partitions (including boot) on a secondary drive
> (Win98 on the primary) - so I used FDISK /mbr to get the Win98 working
> again, but I can't find a way to get into Linux!
> 
> I've tried:
> - running LOADLN off the RedHat CD
> - making a boot floppy from the utilities on the CD (creates disk OK)
> - booting directly from the install CD/floppy using "root=/dev/hdh1"
> 
> and all these start Linux OK but then drop me straight back into the install
> program!? how can I stop this happening - I know it installed OK.
> 
> How can I start Linux properly? Am I writing the correct type of boot disk?
> I'm off to look on the RedHat site for help!
> 
> Cheers
> 
> John

Try booting from the installation media and at the boot prompt
put
vmlinuz root=/dev/XXXX
where XXXX is your root partition.   It should be /dev/hdb1
from what you say.   Then we can hope you can use mkbootdisk
to make a boot floppy.   If Linux doesn't recognize your floppy
at all, I'm not sure what to do.

However, once you've booted Linux, you should be able to run
lilo to make it possible to boot from the hard disk.   I
forget now what the particular error you report means, but
it has been encountered before and a search with deja.com
should suggest how you should deal with it.

If the above method for booting Linux doesn't work, you may
have to use the rescue capabilities of the RedHat 6.2 CD
or some other rescue system.

In further communication, you should let us know some more
technical details about your computer.

-- 

Leonard Evens      [EMAIL PROTECTED]      847-491-5537
Dept. of Mathematics, Northwestern Univ., Evanston, IL 60208

------------------------------

From: Praedor Tempus <[EMAIL PROTECTED]>
Crossposted-To: 
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Wed, 24 May 2000 15:24:03 -0600

David Steuber wrote:
> 
> [EMAIL PROTECTED] (Dowe Keller) writes:
> 
> ' [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> ' >David Steuber <[EMAIL PROTECTED]> writes:
> ' >
> ' >> Do people really have trouble with ./configure, make, make install?
> ' >> It has _never_ been a problem for me.  Maybe I am just lucky.  Even
> ' >> though I changed my compiler, libc, and libtools.
> ' >
> ' >That precise process usually works out fine.  However, a number of
> ' >these processes require manual modification of the Makefile or a
> ' >custom configuration file.  I've also encountered several configure
> ' >scripts that break, and when that happens, you're doomed to rewriting
> ' >the Makefile by hand.  And there are still a few programs that just
> ' >provide you with a grab-bag of Makefiles, and you get to pick which
> ' >one you want.  Those are *always* disasters, but usually the Makefiles
> ' >are at least short enough that fixing them isn't impossible.
> '
> ' Yow, you make it sound like brain surgery. I can count the number of
> ' times that I had to hack Makefiles to get a program to make on the

Ah, then you are fortunate, or you are using a subclass of the software
I use.  I constantly run into problems with the "simple" ./configure,
make, make install process.  It usually derives from ./configure not 
doing its job.  Case in point:  I just tried compiling i3d, a 3d 
graphics modeller using ./configure, etc.  It doesn't work.  Nor has
3dom, nor Mindseye and a host of other apps I've compiled.  I would
say that the failure rate is in the range of 40% which sucks big.

With i3d, configure runs and makes all the makefiles at the end. 
"Ah good", I think, and then run make.  It chugs away for a bit
and finally craps out over qtgl (which IS installed) because it
says it isn't there.  Ahem...if something required for the making
of the source wasn't there, then configure should have found this
out and not gotten far enough to write the makefiles.  At least
with RPM installs I get a pointed list of failed dependencies that
I can easily fix.  With the ./configure game it isn't that simple.
I often DO have the header or lib installed that it is failing to
find and I end up having to tweak the Makefile or experiment with
./configure switches to get it to work (about 60% of the time).
The remaining 40% of the 40% that fail I generally give up on
and look for a precompiled binary since there is something subtle
screwy with what the app wants and what I have...and ./configure
doesn't cut the custard.  It is failing to find the problem.

I do not automatically check the config.log EVERY time I run
./configure.  I should only have to if there is a configuration
failure (and such failure should prevent the Makefiles from being
generated).  

Either config scripts need to be better written or a better system
needs to be developed.  

I haven't used deb packages so I cannot address them but it would be
nice if when installing an rpm (or trying to build a source rpm) and
a dependency fails, then you should be given the automatic option of
downloading the missing rpm rather than just getting a name.  How
about something that follows this script:
========
You: "rpm -Uvh <someapp.rpm>"

This rpm requires <somedependency>
Would you like to download and install the required package(s)? [y/n]

Connecting to...(your preferred ftp or http site or selected from a good 
pre-created but editable list or an option to pull from a CD or
harddrive)

Downloading > ######### (hashing ala installing rpm with -Uvh)

Installing dependency
################ (hashing)
Installing <someapp.rpm>

=======

There.  Done. Little pain or muss and the deed is done without a lot of
dicking
around.  You are up and using the app rather than trying to work out why
you 
can't use it or manually searching for the missing rpms.  It would be
nice as
well if when picking up the dependency rpm it would check to see if IT
has any
particular dependencies to satisfy...

A graphics frontend that can do this would also be nice.  Perhaps
kpackage or
the gnome equivalent could be improved to do this.

Something similar could be done for src.rpms that die for missing
dependencies (I run into this periodically but far less than the problem
arises with ./configure && make && make install).

praedor

------------------------------

From: [EMAIL PROTECTED] (Matthias Warkus)
Crossposted-To: 
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Wed, 24 May 2000 17:17:50 +0200
Reply-To: [EMAIL PROTECTED]

It was the Wed, 24 May 2000 13:00:00 GMT...
...and David Steuber <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Matthias Warkus) writes:
> 
> ' It was the Tue, 23 May 2000 08:59:59 GMT...
> ' ...and David Steuber <[EMAIL PROTECTED]> wrote:
> ' > The right is non-exlusive.  That means everyone can get that right.  I 
> ' > think TrollTech is just trying to prevent forking of the Qt library
> ' > here.
> ' 
> ' Exactly that is which is bad IMHO. Real software freedom has always
> ' been the freedom to fork.
> 
> That's a good point.  But what is the value in real forking?

- Sometimes, forking is good. Look at XEmacs vs. GNU Emacs. It's good
  that we've got both of them, isn't it?

- Better code reuse. Just an example: you've got an FPPLed[0] image
  manipulation program with a really neat and fast algorithm to
  rasterise cutesy little heart shapes. You want to have this
  functionality in an Imlib-like library. You can't because you'd have
  to fork the code off to modify it and redistribute the "modified
  version" as a library.

  Now, you might argue this is not forking, and by some clever
  legalese, one can make code reuse legal and forking illegal. But
  where do you draw the line?

- Enabling people to do the Real Thing(TM). Assume that some company
  develops the FPPLed software package FooPro 2000(TM) which is really
  cool and useful. Unfortunately, its successor, FooPro 2001(TM), is a
  crock, it's taken a design road that you absolutely hate. There are
  some improvements you want to see in FooPro some day, but if the
  official roadmap of FooPro goes on that way, the future versions
  will be horrible.  

  What are you going to do? Persuade the company to incorporate your
  patches and make their design better? Just go with the old FooPro
  2000? You can't just patch FooPro 2000 and release your own version
  -- forking prohibited. Of course you could release megabytes of
  patches and put them on your FTP server next to the original FooPro
  2000 source, but well...

You see, if you can't fork it, the software will effectively remain
controllable by the copyright holder(s).

> Do you really want to have ten different major versions of GTK+
> floating around?  Or even two?  If an application says it uses GTK+
> ver x.y, wouldn't it be simpler to know that the application didn't
> really mean FGTK+ x.y?

Try to find evidence for just *one* fork of that kind. Most forks are
rather benign (like XEmacs/GNU Emacs). I don't know whether any
libraries with established and popular APIs ever forked.

> Linux is held together because people respect the opinion of Linus
> Torvalds.  Even so, there are Alan Cox diffs, RTLinux, and probably
> others.  The tendency is to stick with Linus Torvalds Linux as the
> base.  Will that be true for all GPL projects?  What if some group
> decides a certain feature is needed in GTK+, but another group of
> equal size feels that feature doesn't belong, or should be implemented 
> in a different way, with a different interface?

This is exactly the point: A free software project always depends on a
consensus. If the consensus is lost, the project splits. The software
has got to split along with it, or those people splitting away from
the main branch would lose their rights w/r/t the software package if
they weren't allowed to fork off their version.  

mawa

[0] Fork-Protected Public Licence
-- 
Focus-Leser!
Dankesager!
Defensivfahrer!
Handschuhtanker!

------------------------------

From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: gnu.misc.discuss
Subject: Re: Motif release to Open Source Community leads to Open Motif  Everywhere
Date: Wed, 24 May 2000 21:08:18 +0100
Reply-To: [EMAIL PROTECTED]

On Tue, 23 May 2000 22:26:06 -0700, Jeffrey B. Siegal <[EMAIL PROTECTED]> wrote:
>Jay Maynard wrote:
>> On Mon, 22 May 2000 13:41:29 +0100, phil hunt <[EMAIL PROTECTED]>
>> wrote:
>> >Is AIX being ported to new platforms? No.
>> 
>> W#rong. Monterey is based on AIX.
>
>I would be willing to place a friendly wager that version two of
>Monterey never ships.  Version one may (probably will) ship in order to
>save face and satisfy outstanding commitments, but no one will care. 
>The platform will be quietly abandoned.

I agree with this analysis.


-- 
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months 

------------------------------

From: [EMAIL PROTECTED] (Andrew Purugganan)
Subject: Re: msie 5 for unix on linux
Date: 24 May 2000 21:17:41 GMT

Bob Tennent ([EMAIL PROTECTED]) wrote:
: its monopoly.   BTW I've tried IE on Solaris: it's even more of
: a pig than Netscape.  

didn't think that was possible: to be more of a pig than Nutscrape on 
Linux ;-)
--
jazz  annandy AT dc DOT seflin DOT org
Registered linux user no. 164098
Doesn't it bother you, that we have to search for intelligent life
--- OUT THERE??

------------------------------

From: "John P" <[EMAIL PROTECTED]>
Subject: Re: Redhat 6 install problems...
Date: Wed, 24 May 2000 22:38:54 +0100

> > I've tried:> > - running LOADLN off the RedHat CD
> > - making a boot floppy from the utilities on the CD (creates disk OK)
> > - booting directly from the install CD/floppy using "root=/dev/hdh1"
> >
> > and all these start Linux OK but then drop me straight back into the
install
> > program!? how can I stop this happening - I know it installed OK.
> >
> > How can I start Linux properly? Am I writing the correct type of boot
disk?
> > I'm off to look on the RedHat site for help!
> >
> > Cheers
> >
> > John
>
> Try booting from the installation media and at the boot prompt
> put
> vmlinuz root=/dev/XXXX
> where XXXX is your root partition.   It should be /dev/hdb1
> from what you say.   Then we can hope you can use mkbootdisk
> to make a boot floppy.   If Linux doesn't recognize your floppy
> at all, I'm not sure what to do.
>
> If the above method for booting Linux doesn't work, you may
> have to use the rescue capabilities of the RedHat 6.2 CD
> or some other rescue system.
>

I think it's a bit of a "non-standard installation.." I've just checked some
files on the RedHat site (BTW, the version I am installing is 6.1) and have
found out that the hard disk Linux is installed on is on the "quaternary IDE
channel" (on a Soundblaster AWE32 IDE channel)..

Don't think that's the main problem as it recognises and boots to /dev/hdh1
OK, but when it does, it goes straight into the RedHat installation program.

How can I stop it doing this? I think (but am guessing completely here) that
a "successful" installation reboots and then goes into Linux via LILO,
whereupon it gets told the installation is complete, and can stop running
the install program?? But could it be as the LILO config screwed up, it
never got that far, and this is some failed-install recovery thing?

I have downloaded a rescue disk image and will try that now... otherwise I
may just wipe the disk and start over (not using LILO this time..)

Thanks
John





------------------------------

Crossposted-To: 
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.development.system
Subject: Re: Need ideas for university funded project for linux
From: [EMAIL PROTECTED]
Date: Wed, 24 May 2000 21:42:25 GMT

[EMAIL PROTECTED] (Leslie Mikesell) writes:
> In article <[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:
> >David Steuber <[EMAIL PROTECTED]> writes:

> >> If Windows is so great, why do you have to reboot when you change your 
> >> IP address?

> >You don't.

> For 1 value of windows.  

Granted.  But they've at least recognized that it's a problem and have
fixed it.

> Why do you have to reboot when you change the machine name?

In an NT/2K environment, probably because you're logged in via the
server service.  So if you login to APATHOS as Administrator, you're
APATHOS\Administrator (even if it's just a workgroup instead of a
domain).  So when you change the machine name, your login becomes
invalid and authentication will fail.  Even if you're not logged in
*over* the network, but through a loopback connection or even just
locally, the system still makes it look like you're signed on over the
network.

I don't know this for a fact, but it certainly makes sense to me.
Now, you may want to make a case for the brokenness of SMB, but if I'm
right, then Windows is at least doing it properly.

-- 
Eric P. McCoy ([EMAIL PROTECTED])

non-combatant, n.  A dead Quaker.
        - Ambrose Bierce, _The Devil's Dictionary_

------------------------------

From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: how to enter a bug report against linux?
Date: 24 May 2000 16:55:17 -0500

In article <8ghffc$l6s$[EMAIL PROTECTED]>,
Peter T. Breuer <[EMAIL PROTECTED]> wrote:

>: This is fine for the handful of people who are working to solve
>: current bugs.  It is not so fine for the millions of people who
>: are trying to work around what should be well understood bugs
>: in released versions.
>
>They wouldn't know a bug if it bit them in the nose and deleted every file
>whose name ends in "e".

Beg your pardon?  Do you think no one cared about the e2fs bugs
causing data to be lost on systems running 2.2.7 (or so, it is
hard to get good info) to 2.2.10 kernels?

>It's the kernel developers and maintainers who
>are interested in the bugs ,and they're interested in _getting_ bug
>reports, because that's the hard bit.

Then a central repository would be a good thing.

>: This is irrelevant to someone whose system has to work now.
>
>They contact the newsgroup defence line for their distro. Kernel
>list lurkers  often answer there, if required, but 9999 times out of
>ten thousand, they are looking at an application bug or a distro bug
>or a configuration bug.

Nice try.  How about NFS?  

>:>It is very hard to locate or even describe a kernel bug.
>
>: Again, a correct description is only relevant to a couple of
>: people.  The rest of the world just needs to know what circumstances
>: break what thing, how to avoid it, and when it is fixed so they
>: can stop taking those measures to avoid it.
>
>You miss my point. I am saying that a kernel bug is INTRINSICALLY hard
>to define. How do you know if the kernel is wrong? What is the standard
>against which you are measuring it?

The usual practice is to build regression tests for as much as
possible so you actually have an answer for this.  The people
doing bug tracking then can also tell when it is fixed and
close the problem.
 
>It might be a legitimate behaviour,
>and it might be the application that is broken. Nobody except a real
>real expert can tell, and even then it's only an opinion. Lusers have
>not a hope.

Can you imagine the response if this particular comment appeared
in a Microsoft knowlege base? 

>: It should never be necessary for a developer to tell someone else
>: how to work around bugs.  That is the real reason that bug tracking
>
>Sure it should. Do you think they like sitting around in a cubicle all
>day? Go 'way. You're no fun.

I think you underestimate the number of people who need this kind
of answer or the time it would take to supply the correct ones.

>: And this is the list that you are suggesting that end users or
>: administrators would use to see if a bug is already known?
>
>You are purloining my words and selling them cheaply, while mixing
>my aphorisms ...  I am telling you that the end users can go dance in
>hell, because you have a straw man there.

Great.  Just don't suggest Linux as an alternative to supported 
systems without letting people know what they are getting into.
I happen to enjoy a challenge myself, but that isn't true for
everyone.

>There is no way a luser can
>find or recognize a kernel bug that hasn't already been dealt with on
>their distros newsgroups.

Hmmm...

>If they're real interested they can sign up to
>the list or browse archives on deja.  At several hundred mails a day,
>they'll be looking till kingdom come!  If they're less interested they
>can ask on a newsgroup, and let somebody who is filtering the stuff
>through his brain answer.  And they can check the newsgroup archives
>too!  Have a look at c.o.l.s.  If they're really sure enough of
>themselves to think they have detected a bug, they can post the mailing
>list or the maintainer concerned.  It is usually polite to post the list
>first to get general feedback.  If the resulting furore gets loud enough
>the maintainer will pick it out of the kernel list noise and come
>looking for you.

Do you mind if I quote this the next time someone asks if Linux
is suitable for some particular job?

>Some lists are low volume. The eepro100 lists for example generally
>spurt at up to about 10 a day, and then are silent for a while. Depends
>on whether some interesting new chip/bug has been found. Lot's of
>the eepro100 traffic actually turns up on the kernel list, for
>"complicated" reasons involving various personalities. One can browse
>those lists archives easily. And of course you can just read the driver
>source comments and the web pages to see the bug history.

Once upon a time I tried to run a windows program under VMWare
that listened to a network broadcast.  It didn't work.  Why
was it impossible at the time for me to find out that there
was a problem with the eepro100 and multicasts and thus
didn't have anything to do with VMWare?  (I only know now because
I noticed the fix mentioned in a changelog sometime since, and
it does work correctly now).

>If you volunteer to host a bugtracker, btw, everyone will be happy.
>It's no skin off anyone's back.  But getting people to actually
>use it is a social problem you should solve!

OK, the fact that no one wants to do it is a legitimate issue for
an all-volunteer effort. But you could have admitted that in
the first place instead of trying to claim that it is not
needed or wanted.

>The plain fact is that
>point bugs are found and solved in hours .. way faster than a
>bug tracking system can get in on.

How many releases contained the e2fs bug?  I don't think any
2.2.x kernel has had kernel NFS right.  Bugs are going to crop up
everywhere and people have to know about them to avoid and
work around the problems.

>And the n-n communication is part of
>that. It's Linus' "all bugs are visible to many eyes" line. Put
>up a bugtrack system and you reduce the coommunication to n-1. You
>isolate the developers from each other. That's no good.

Just the opposite.  I generally assume that there are enough other
people reporting bugs and just try to work around them.  If there
were a handy way to see the known bugs for any version, I would
know when I hit something new and go to the effort of reporting it.

  Les Mikesell
   [EMAIL PROTECTED]

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Print in Landscape orientation
Date: Wed, 24 May 2000 21:53:27 GMT

Try the program    mpage



In article <[EMAIL PROTECTED]>,
  hauck[at]codem{dot}com wrote:
> On 24 May 2000 14:51:26 GMT, Stearns25 <[EMAIL PROTECTED]> wrote:
>
> >We have several text-based spreadsheets that needed to be printed in
Landscape
> >orientation.
>
> Assuming that you have a postscript printer, or have ghostscript set
up as
> a filter to drive some other kind of printer, look at the man page for
> "enscript".
>
> --
>  -| Bob Hauck
>  -| Codem Systems, Inc.
>  -| http://www.codem.com/
>


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

Crossposted-To: 
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
From: [EMAIL PROTECTED]
Date: Wed, 24 May 2000 22:02:05 GMT

"Anthony W. Youngman" <[EMAIL PROTECTED]> writes:

> >> I am led to believe (in other words I may well be wrong...) that rpms
> >> basically have a required/not-required status. If the system MAY require
> >> a package, then either it is flagged as required and the system tries to
> >> make you install it, or it's not flagged and gets ignored.

> >Well, technically, some is either required or it isn't.  If you're
> >right (I have no idea), the problem seems to be more on the package
> >maintainer's end, rather than the rpm developer's end.

> But you're ignoring the example packages I (deliberately) chose ...

> If I have an ISDN card, then I *NEED* ISDN4LINUX, if I don't then it's a
> waste of space. Same with a sound card and OSS.

You *need* it?  As in, you won't be able to use your system at all
unless you have it?

I'm deliberately choosing a black-and-white perspective here, because
you're saying that's what rpm has.  But it's not totally unjustified;
raw ISDN support is done in the kernel, correct?  If so, should the
package manager communicate with the kernel to determine if a package
should be required?

Really, it seems clear to me that ISDN4LINUX and OSS are not
required.  They are useful if you have the appropriate hardware, but
if not having them doesn't break your system, then they just aren't
needed.  I can think of lots of reasons not to use OSS even if you
have a sound card.  The case is weaker for ISDN - because no
computers, to my knowledge, ship with it installed - but maybe one
could still be made.

Note that your suggestion (marking something "optional") is
practically identical to marking something not-required, except for
package grouping.  Optional packages aren't installed by default, so
you have to select them manually.  Not-required packages aren't
installed by default, so you have to select them manually.  The same
degree of effort is involved in both.

> If that hardware is present, then those packages are REQUIRED. If the
> hardware isn't there then those packages are a waste of space (and on
> the system I was complaining about, it was more than 1% of the available
> disk space for ISDN4LINUX alone - that's space I can't spare).

Well, you can always remove them.  I see your complaint, though.

> As somebody else pointed out, rpms can't have conditional dependency.
> Either it's flagged as "required" and I scream blue murder because the
> basic install on my mum's pc crashes with a "disk full", or it's flagged
> as "not required" and I scream blue murder because it doesn't install on
> the office server and I need it.

I'm going to have to disagree with you here, just on technical
reasons.  To implement the kind of conditional dependency you want
(which Debian tries to do and screws up royally [1]), you'd need help from
the kernel.  It could certainly be done, but I don't like the idea of
tying rpm or dpkg or whatever to a specific kernel.

Perhaps a separate program which *is* tied to a specific kernel and
reports on what hardware is installed?  It'd be really simple; its
only job would be to get /proc/pci and friends in an
architecture-independent format.  This could also be used in the
install process to autoselect some modules the user is likely to want.

-- 
Eric P. McCoy ([EMAIL PROTECTED])

non-combatant, n.  A dead Quaker.
        - Ambrose Bierce, _The Devil's Dictionary_

[1] Having two separate "enlightenment" and "enlightenment-nosound"
  packages that differ only in their dependencies is, in my opinion,
  broken packaging.

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and comp.os.linux.misc) via:

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Misc Digest
******************************

Reply via email to