further debian questions

further debian questions

[James Miller]

Well, I decided on what appeared to be the most user-friendly of the
commercial Debian variants to go on my machine - Libranet. So far, I'm not
as happy with it as I was with Knoppix. For one thing, it seems that
apt-getting is a restricted process under Libranet. They have an app
called "Aptitude" that, I've discovered, one should by all means use for
installing new packages. Here's the way I learned this: I noted that there
were some dependency problems with WINE (more on that later), so I decided
to apt-get it using Aptitude. I was not having much success, so I said to
myself: "why I am I screwing around with this Aptitude prophylactic when I
can just open a console and apt-get the thing?" So, that's what I did.
Well, for the first time in my breif apt-getting career, I got a message
saying there were dependency problems, and a list of the missing
dependencies. So, I says to myself: "heck, I better get those dependencies
so's I can install my prog." So, I went first after one called "libarts."
Big mistake. Installing libarts caused major portions of KDE to be
deleted: apparently what happend is that I got libarts from stable Debian,
which, as I understand it, is part of KDE and KDE in stable Debian is 2.x
while I had KDE 3.x on my Libranet system. To make a long story short, the
most expedient way of restoring KDE proved to be reinstalling Libranet.
So, I decided I may only apt-get at my own risk on this system, most of
the time being constrained by Aptitude and its peculiarities.

Here's another problem I've had. I tried to get Lyx using Aptitude, but
have again encountered dependency problems. My question regarding this is
whether dependency problems are endemic to apt-get as they are to the
package installing methods of other well-known distros? I never ran into
any dependency problems on the Knoppix test system I had when trying to
apt-get. Was I simply lucky? Are the dependecy problems I'm having
traceable to shortcomings in Aptitude, or are they part of life using
apt-get from a console as well?

Finally, does it seem to you, as it does to me, that my initial problems
with WINE are a reflection of deficiencies in the distro I'm using? I can
see no reason why I should have dependecy problems on a freshly installed
system. I was never asked during the install process whether I wanted to
leave out any libraries or anything. Rather, I selected pretty much the
default install option, adding a couple of additional package groups from
the list with which I was presented. That indicates to me that either they
have poorly constructed this distribution, leaving out key elements of an
important package, or else their Aptitude program is buggy and is wrongly
reporting dependency problems. If either of these are true, I question
whether I should go through with payment on this distro, since it seems
still to be at the beta stage.

Feedback from the more knowledgeable on this list will be appreciated.

James

PS I have not succeeded in running any program under WINE, though I have
not spent a great deal of time trying. Whether problems lie with the
dependency issues Aptitude reports, or just WINE's inherent buginess,
I cannot say for sure at this point.

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: further debian questions

[Ray Olszewski]

First the basic comment: apt-get (and its cousin, apt-cache) are just tools 
for managing the process of installing packages from source archives. You 
tell us that you used apt-get to install things, but you don't say where 
you installed them from (that is, what archives are listed in 
/etc/apt/sources.list). aptitude is just a standard Debian alternative to 
apt-get and apt-cache (it also uses /etc/apt/sources.list, for example), so 
switching between the two should not *itself* introduce any problems ... 
though I don't use aptitude myself. Unless, of course, Libranet has 
modified any of these apps to cause them to depart from standard Debian usage.

As a general matter, when used consistently on a single archive, apt-get is 
superb at handling dependency problems. I run Debian Unstable (Sid) mostly, 
plus a little Debian Stable (Woody) ... I NEVER have a problem with Woody, 
and only rarely with Sid (they call it Unstable for a reason, and 
occasionally a package gets updated before a dependency, but the mismatch 
normally is fixed quickly). In fact, in my experience, you never have to 
"get those dependencies
so's I can install my prog" ... apt-get automatically identifies 
dependencies and installs the needed packages to satisfy them.

As to your specific wine problems, I can't suggest anything concrete based 
on what you've posted, because I can't confirm what you say. For example, 
you write

>Well, for the first time in my breif apt-getting career, I got a message
>saying there were dependency problems, and a list of the missing
>dependencies. So, I says to myself: "heck, I better get those dependencies
>so's I can install my prog." So, I went first after one called "libarts."
>Big mistake.

I don't know why apt-get listed libarts as a dependency problem associated 
with wine, because my (Sid) archives does not include libarts among the 
packages wine depends on:
         autovcr@kuryakin:~$ apt-cache show wine
         Package: wine
         [...]
         Depends: debconf, libwine (= 0.0.20021125-1), xbase-clients (>= 
4.0) | xcontrib
         Suggests: wine-doc, winesetup, msttcorefonts, binfmt-support
         Conflicts: binfmt-support (<< 1.1.2)

You then write:

>  Installing libarts caused major portions of KDE to be
>deleted: apparently what happend is that I got libarts from stable Debian,
>which, as I understand it, is part of KDE and KDE in stable Debian is 2.x
>while I had KDE 3.x on my Libranet system.

This puzzles me, because apt-get and aptitude are supposed to use the same 
/etc/apt/sources.list to get their package lists; I don't understand what 
Libranet did to them to cause them to access different package archives. 
Nor do I quite understand what you mean by "deleted" ... dependency 
problems can cause package not to operate properly, but they don't 
typically depete files. (Unless you did a "dist-upgrade" in there somewhere 
... this option causes apt to be a bit more aggressive in trying to resolve 
particularly ugly dependency mismatches, and using it with a downgrade -- 
from unstable to stable -- might do anything.)

The main lesson is to stick to a single archive ... even mixing Woody and 
Sid packages is not for the inexperienced.

Final comment -- you write:

>I can see no reason why I should have dependecy problems on a freshly 
>installed
>system.

Actually, missing dependencies are commonplace on all full-size Linux 
systems, because, increasingly, packages use a wide mix of libraries, far 
too many possibilities to install them all in a base install. Also, some 
packages use libraries with licensing problems (e.g., some audio and video 
codecs), and you need to install them from "unofficial" archives, not the 
base Debian ones. Systems like apt do more than identify the missing 
dependencies; they automatically install them for you, for this very reason 
... so they do not become a "problem". (I'm not current on using rpm-based 
tools, but I've no doubt they handle missing dependencies in some manner 
analogous to apt-get's approach.)

It may be that Libranet has introduced some problems in spinning off from 
Debian Woody. Or you may have made some mistake that I'm not seeing from 
your description of what you did. Personally, I'd think your best bet was 
to move away from  "commercial Debian variants" completely and use Debian 
itself. Or, since you seem to be *paying* for Libranet, to get some serious 
technical support from them.

At 11:06 AM 12/24/02 -0600, James Miller wrote:
>Well, I decided on what appeared to be the most user-friendly of the
>commercial Debian variants to go on my machine - Libranet. So far, I'm not
>as happy with it as I was with Knoppix. For one thing, it seems that
>apt-getting is a restricted process under Libranet. They have an app
>called "Aptitude" that, I've discovered, one should by all means use for
>installing new packages. Here's the way I learned this: I noted that there
>were some dependency problems with WINE (more on that later), so I decided
>to apt-get it using Aptitude. I was not having much success, so I said to
>myself: "why I am I screwing around with this Aptitude prophylactic when I
>can just open a console and apt-get the thing?" So, that's what I did.
>Well, for the first time in my breif apt-getting career, I got a message
>saying there were dependency problems, and a list of the missing
>dependencies. So, I says to myself: "heck, I better get those dependencies
>so's I can install my prog." So, I went first after one called "libarts."
>Big mistake. Installing libarts caused major portions of KDE to be
>deleted: apparently what happend is that I got libarts from stable Debian,
>which, as I understand it, is part of KDE and KDE in stable Debian is 2.x
>while I had KDE 3.x on my Libranet system. To make a long story short, the
>most expedient way of restoring KDE proved to be reinstalling Libranet.
>So, I decided I may only apt-get at my own risk on this system, most of
>the time being constrained by Aptitude and its peculiarities.
>
>Here's another problem I've had. I tried to get Lyx using Aptitude, but
>have again encountered dependency problems. My question regarding this is
>whether dependency problems are endemic to apt-get as they are to the
>package installing methods of other well-known distros? I never ran into
>any dependency problems on the Knoppix test system I had when trying to
>apt-get. Was I simply lucky? Are the dependecy problems I'm having
>traceable to shortcomings in Aptitude, or are they part of life using
>apt-get from a console as well?
>
>Finally, does it seem to you, as it does to me, that my initial problems
>with WINE are a reflection of deficiencies in the distro I'm using? I can
>see no reason why I should have dependecy problems on a freshly installed
>system. I was never asked during the install process whether I wanted to
>leave out any libraries or anything. Rather, I selected pretty much the
>default install option, adding a couple of additional package groups from
>the list with which I was presented. That indicates to me that either they
>have poorly constructed this distribution, leaving out key elements of an
>important package, or else their Aptitude program is buggy and is wrongly
>reporting dependency problems. If either of these are true, I question
>whether I should go through with payment on this distro, since it seems
>still to be at the beta stage.
>
>Feedback from the more knowledgeable on this list will be appreciated.




--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
-------------------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: further debian questions

[Heimo Claasen]

I feel quite confused when reading this:

> The main lesson is to stick to a single archive ... even mixing Woody and
> Sid packages is not for the inexperienced.

What, then, would be the use of "upgrades" at all" ?

And the conclusion would not be that general for installing packages
from "earlier" distributions (or their versions) either - I regularly
install a quite "old" application, which is rather demanding in its X
(server) use, with all sorts of "modern" distributions and hitherto
never had a problem with it.

The reason for that "main lesson" given then, seems rather questionable:
> Actually, missing dependencies are commonplace on all full-size Linux
> systems, because, increasingly, packages use a wide mix of libraries, far
> too many possibilities to install them all in a base install.

Commonplace indeed, and "absolutely", as they would say in a BBC
interview.

It appears to me that a response to this condition rather would be,
(a) an advice to authors (or packagers) to join clear indications of
needed third components [ - and I work with one rather experimental
development where this is done exemplarly - ], and
(b) hints about how to best handle "complicated" cases; most probably,
these would be conflicts _among_ "dependencies".

In respect to the latter, the Debian "deselect" package installation
does a good job in offering choice directly (i.e., to install a
"conflicting" component - which would then delete the earlier
installed other component it would be in conflict with -) but it is
not at all very verbose. While the Mandrake "Package Manager", for
instance, is quite better in informing what the conclict/s is/are but
leaves it to "manual" work to delete the other compondetn first in order
to install the first. And both can put a user - not only a newbie - in
a dilemma with the sametimes arcane terminology.

Though I find the most irritating types of "dependencies" being those
_on_ which a specific programme/application is built - sometimes I had
to go through four or five levels (or steps, if you want) in such a
chain only to detect that all the other dependencies are with
superfluous or obsolete progs. But to throw these out - without
playing havoc with the whole "system" - and guarding precisely what's
really needed, is enormously tiresome.

Some of the "full size" Linux installations came up to more than 90 000
files here; together with some confusing traditions (put this thing in
/bin/usr but not in /usr/bin, the other thingy precisely the other way
round, etc) and the permissions djungle, this results in quite an
invitation to intransparency and trouble potential.

(BTW, I seriously question the commonly affirmed advantages of
especially libraries sharing - in reality, quite some of them are so
highly specific that already a small change in a new version of a
programme which depends on one of them needs a new library; to be
"shared, of course.  Question is, by whom.  The whole handling of the
"system", and certainly in most cases its sheer volume, would be easier
with a more balanced judgement of program authors on what to include and
what to be "outsourced".)

((And BTW2, please don't thrash this ideological verbosity of the
"powerful" nature of the "system" in this context - it's easy enough to
show how the n! possible combinations of trouble increase with n.))

// Heimo Claasen // <hammer at revobild dot net> // Brussels 2002-12-25
The WebPlace of ReRead - and much to read  ==>  http://www.revobild.net

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

RE: further debian questions

[james miller]

As usual, helpful suggestions, Ray. Thank you. As I often do, I seem to have 
mistakenly presumed my first exposure to a given component (Aptitude) as more 
peculiar to the context in which I encountered it (the Libranet distro) than 
it really is. So, I now learn that this is a Debian application. Thanks for 
making that clear.  Overall, my experience with the HD install of Knoppix was 
far superior to what I've had with Libranet. I went with either/both of those, 
btw Ray, because of what I've heard (and a bit of what I've seen) about 
difficulties in installing real Debian. I thought these 2 would spare me some 
newbie nightmares. At least in the case of Libranet though, it seems I was 
mistaken. In addition to other problems I've had with it, it's also not 
dealing well with my modem (for whatever unfathomable reason - I never had any 
modem problem under Knoppix). I may end up taking your advice, Ray, and just 
going with straight Debian.   James

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

RE: further debian questions

[james miller]

As usual, helpful suggestions, Ray. Thank you. As I often do, I seem to have 
mistakenly presumed my first exposure to a given component (Aptitude) as more 
peculiar to the context in which I encountered it (the Libranet distro) than 
it really is. So, I now learn that this is a Debian application. Thanks for 
making that clear.  Overall, my experience with the HD install of Knoppix was 
far superior to what I've had with Libranet. I went with either/both of those, 
btw Ray, because of what I've heard (and a bit of what I've seen) about 
difficulties in installing real Debian. I thought these 2 would spare me some 
newbie nightmares. At least in the case of Libranet though, it seems I was 
mistaken. In addition to other problems I've had with it, it's also not 
dealing well with my modem (for whatever unfathomable reason - I never had any 
modem problem under Knoppix). I may end up taking your advice, Ray, and just 
going with straight Debian.   James

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: further debian questions

[Ray Olszewski]

At , Heimo Claasen wrote:
>I feel quite confused when reading this:
>
> > The main lesson is to stick to a single archive ... even mixing Woody and
> > Sid packages is not for the inexperienced.
>
>What, then, would be the use of "upgrades" at all" ?

Well ... are you and I using "upgrade" in the same way? In the context of 
the Debian apt-* system, the "upgrade" command tells apt-get to check which 
installed packages are not the current versions in the archive, and replace 
any that are not current with the current ones (with some minor 
exceptions). It is NOT the command one uses when (for example) moving a 
system from Woody to Sid ... that is a "dist-upgrade", whihc addresses 
dependencies a bit differently. The "upgrade" options is properly, and 
quite usefully, used only *within* a version to keep it current (to get 
security upgrades and bugfiles, mainly).

>And the conclusion would not be that general for installing packages
>from "earlier" distributions (or their versions) either - I regularly
>install a quite "old" application, which is rather demanding in its X
>(server) use, with all sorts of "modern" distributions and hitherto
>never had a problem with it.

You describe your experience here too vaguely for me to be able to comment 
intelligently. Except to note that dependency problems usually relate to 
libraries, not X servers (does this "quite 'old' application" use libc6, 
for example, and how did it cope with the change from glibc2.0.x to 
glibc2.1.x?).

>The reason for that "main lesson" given then, seems rather questionable:
> > Actually, missing dependencies are commonplace on all full-size Linux
> > systems, because, increasingly, packages use a wide mix of libraries, far
> > too many possibilities to install them all in a base install.

[...]

>It appears to me that a response to this condition rather would be,
>(a) an advice to authors (or packagers) to join clear indications of
>needed third components [ - and I work with one rather experimental
>development where this is done exemplarly - ], and

Were this a list that gave advice to package developers (or authors or 
packagers), I might agree with you. But offering such advice *here* is 
pointless, since the people who come here for advice are beginners trying 
to get Linux to work., not developers and others trying to improve their 
packaging practices. Advice *here* should help those people cope with 
reality, not focus on how packaging might be better.

>(b) hints about how to best handle "complicated" cases; most probably,
>these would be conflicts _among_ "dependencies".

These problems need to be handled on a case-by-case basis. Perhaps others 
can suggest useful "hints" that are not specific to a particular problem, 
but I have none to offer, especially since (apparently) I use sufficiently 
well-behanved apps that Debian-Sid (or Debian-Woody, for older, more stable 
apps) can handle dependencies properly for me.

One option you don't mention ... though you hint at it in a part of your 
message that I deleted here ... is static compilation. A developer (or a 
user who compiles from source) can bypass dependency issues completely by 
doing a static compile against the library versions he or she wants the 
program to use. The price is bigger code (both on disk and in memory), but 
for the highly specialized applications you focus on in your comments, it 
might be worth considering. But again, this though too is more useful to 
experienced users and developers than to true beginners.

[remainder deleted]


--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski					-- Han Solo
Palo Alto, California, USA			  ray@comarre.com
-------------------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs