* RE: further debian questions
@ 2002-12-26 6:24 james miller
0 siblings, 0 replies; 6+ messages in thread
From: james miller @ 2002-12-26 6:24 UTC (permalink / raw)
To: linux-newbie
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: further debian questions
@ 2002-12-26 6:24 james miller
0 siblings, 0 replies; 6+ messages in thread
From: james miller @ 2002-12-26 6:24 UTC (permalink / raw)
To: linux-newbie
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: further debian questions
@ 2002-12-26 0:00 Heimo Claasen
2002-12-26 17:24 ` Ray Olszewski
0 siblings, 1 reply; 6+ messages in thread
From: Heimo Claasen @ 2002-12-26 0:00 UTC (permalink / raw)
To: linux-newbie
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: further debian questions
2002-12-26 0:00 Heimo Claasen
@ 2002-12-26 17:24 ` Ray Olszewski
0 siblings, 0 replies; 6+ messages in thread
From: Ray Olszewski @ 2002-12-26 17:24 UTC (permalink / raw)
To: linux-newbie
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* further debian questions
@ 2002-12-24 17:06 James Miller
2002-12-24 17:55 ` Ray Olszewski
0 siblings, 1 reply; 6+ messages in thread
From: James Miller @ 2002-12-24 17:06 UTC (permalink / raw)
To: linux-newbie
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: further debian questions
2002-12-24 17:06 James Miller
@ 2002-12-24 17:55 ` Ray Olszewski
0 siblings, 0 replies; 6+ messages in thread
From: Ray Olszewski @ 2002-12-24 17:55 UTC (permalink / raw)
To: linux-newbie
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-12-26 17:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-26 6:24 further debian questions james miller
-- strict thread matches above, loose matches on Subject: below --
2002-12-26 6:24 james miller
2002-12-26 0:00 Heimo Claasen
2002-12-26 17:24 ` Ray Olszewski
2002-12-24 17:06 James Miller
2002-12-24 17:55 ` Ray Olszewski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox