To dselect or aptitude, that is the question
J.S.Sahambi
about the advantages/disadvantages of dselect and aptitude? and which is
better?
Thanks in advance
JSS
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Florian Ernst
On Tue, Apr 20, 2004 at 11:51:19AM +0530, J.S.Sahambi wrote:
> I have been using apt and dselect for some time. Can any body tell me
> about the advantages/disadvantages of dselect and aptitude? and which is
> better?
To dselect or aptitude, that is the question;
Whether 'tis nobler in the mind to suffer
The slings and arrows of outragous dselect
where, alas, Sarge can barely meet Sid
Or to take arms against a sea of troubles
And by learning aptitude end them.
But seriously, both have their (dis)advantages, use them, feel them,
decide yourself. Better is what you can make out of them.
Cheers,
Flo - who was a dselect advocate for a long time and then switched to
aptitude because of its ability to easily handle mutliple releases.
I stayed there, and I don't regret it.
PS: Sorry to Mr. 'Speare and to all poets for the butchering...
Karsten M. Self
> Hello J.S.!
>
> On Tue, Apr 20, 2004 at 11:51:19AM +0530, J.S.Sahambi wrote:
> > I have been using apt and dselect for some time. Can any body tell me
> > about the advantages/disadvantages of dselect and aptitude? and which is
> > better?
>
> To dselect or aptitude, that is the question;
> Whether 'tis nobler in the mind to suffer
> The slings and arrows of outragous dselect
> where, alas, Sarge can barely meet Sid
> Or to take arms against a sea of troubles
> And by learning aptitude end them.
>
>
> But seriously, both have their (dis)advantages, use them, feel them,
> decide yourself. Better is what you can make out of them.
aptitude is pretty much a replacement for both dselect (interactive) and
apt-get (command line). With near but not-quite drop-in replacement of
the latter. The strengths go beyond this to include logging of system
updates, allegedly, though I'm still not fully clear on how/where.
I found tonight that the difference between an 'apt-get dist-upgrade'
and an 'aptitude dist-upgrade' for an older system which I've been
attempting to pare down (former desktop, now mostly a DNS / remote
access server) was about 280 MiB.
The short answer, though, is that you'd want aptitude over dselect in
virtually all instances. Though apt-get is still useful. Look also at
synaptic and, um, the other stuff.
> Cheers,
> Flo - who was a dselect advocate for a long time and then switched to
> aptitude because of its ability to easily handle mutliple releases.
> I stayed there, and I don't regret it.
>
>
> PS: Sorry to Mr. 'Speare and to all poets for the butchering...
Oh brave new world, that has such features in't....
Peace.
--
Karsten M. Self <kms...@ix.netcom.com> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Enough is as good as a feast.
Florian Ernst
On Tue, Apr 20, 2004 at 12:39:48PM -0700, Karsten M. Self wrote:
> aptitude is pretty much a replacement for both dselect (interactive) and
> apt-get (command line). With near but not-quite drop-in replacement of
> the latter. The strengths go beyond this to include logging of system
> updates, allegedly, though I'm still not fully clear on how/where.
Do you mean the log in /var/log/aptitude ? Has already helped me in
explaining quite a lot of strange things...
> [...]
> The short answer, though, is that you'd want aptitude over dselect in
> virtually all instances. Though apt-get is still useful. Look also at
> synaptic and, um, the other stuff.
>
> > Flo - who was a dselect advocate for a long time and then switched to
> > aptitude because of its ability to easily handle mutliple releases.
> > I stayed there, and I don't regret it.
I really mean that :)
Nowadays I solely use aptitude and apt-get source / build-dep (and
occasionally a direct dpkg). The only thing I miss is dselect's
feature to show me a dependency resolution screen directly after
(de)selecting a package, but aptitude's other features more than
compensate for this.
Now if someone please ported aptitude to hurd so I can get rid of
dselect there as well... ;)
Still, I think it up to everyone to pick his tool, and if someone
after some testing really prefers dselect, well, I won't stop him.
Cheers,
Flo
Alex Malinovich
--snip--
> Nowadays I solely use aptitude and apt-get source / build-dep (and
> occasionally a direct dpkg). The only thing I miss is dselect's
> feature to show me a dependency resolution screen directly after
> (de)selecting a package, but aptitude's other features more than
> compensate for this.
> Now if someone please ported aptitude to hurd so I can get rid of
> dselect there as well... ;)
>
> Still, I think it up to everyone to pick his tool, and if someone
> after some testing really prefers dselect, well, I won't stop him.
I prefer dselect for the one task that I use it for, and that's
dist-upgrades with the dependency resolution screen. The rest of the
time I use wajig. The only thing that I can't do that I wish I could
(And someone please fill me in if you know of a way) is remember which
packages got brought in for installation of package 'a'. So when I
remove package 'a' it'll remove it and all of the packages that were
brought in with it.
--
Alex Malinovich
Support Free Software, delete your Windows partition TODAY!
Encrypted mail preferred. You can get my public key from any of the
pgp.net keyservers. Key ID: A6D24837
Florian Ernst
On Tue, Apr 20, 2004 at 03:37:01PM -0500, Alex Malinovich wrote:
> I prefer dselect for the one task that I use it for, and that's
> dist-upgrades with the dependency resolution screen. The rest of the
> time I use wajig. The only thing that I can't do that I wish I could
> (And someone please fill me in if you know of a way) is remember which
> packages got brought in for installation of package 'a'. So when I
> remove package 'a' it'll remove it and all of the packages that were
> brought in with it.
AFAIK outside of aptitude you'll need debfoster for this, but you
probably know this...
Cheers,
Flo
Graham Williams
> On Tue, 2004-04-20 at 15:08, Florian Ernst wrote:
> I prefer dselect for the one task that I use it for, and that's
> dist-upgrades with the dependency resolution screen. The rest of the
> time I use wajig. The only thing that I can't do that I wish I could
> (And someone please fill me in if you know of a way) is remember which
> packages got brought in for installation of package 'a'. So when I
> remove package 'a' it'll remove it and all of the packages that were
> brought in with it.
Hi Alex,
I think there's something like this in wajig: purge-depend. This will
purge a package and those it depend on and not required by others. Not
exactly what you were asking, but close?
Regards,
Graham
----
Katipo
>On Wed, 2004-04-21 at 06:37, Alex Malinovich wrote:
>
>
>>On Tue, 2004-04-20 at 15:08, Florian Ernst wrote:
>>
>>
>[...]
>
>
>>I prefer dselect for the one task that I use it for, and that's
>>dist-upgrades with the dependency resolution screen. The rest of the
>>time I use wajig. The only thing that I can't do that I wish I could
>>(And someone please fill me in if you know of a way) is remember which
>>packages got brought in for installation of package 'a'. So when I
>>remove package 'a' it'll remove it and all of the packages that were
>>brought in with it.
>>
>>
>
>Hi Alex,
>
>I think there's something like this in wajig: purge-depend. This will
>purge a package and those it depend on and not required by others. Not
>exactly what you were asking, but close?
>
>
>
I believe 'dpkg --purge <package>' does this also.
After a period aptitude also recognises unused packages, and removes
them, making a note of it enroute.
I find that I tend to use aptitude for single package/mini upgrade
procedures, and dselect for major upgrade/dist-upgrade scenarios.
dpkg --purge <package> for removal, because it does such a good job of
it, and aptitude autoclean to keep things tidy.
With using different agents in this nature, even though they employ the
same apt-cache, I find it advantageous to employ the appropriate update
command with each one before employing them. Otherwise, you can find
yourself in a bit of a mess.
I speak as one who has been scuffling round in the nether depths of the
local rubbish dump, searching for dependencies and mysteriously missing
programmes.
Regards,
David.
W Paul Mills
> The short answer, though, is that you'd want aptitude over dselect in
> virtually all instances. Though apt-get is still useful. Look also at
> synaptic and, um, the other stuff.
Yet I have found instances when dselect seems to handle errors better than
aptitude. At least gives a meaningfull message so you can figure out how to
fix the problem. Still I use aptitude, unless I get stuck.
Paul
--
/********************** Running Debian Linux ************************
* For God so loved the world that He gave his only begotten Son, *
* that whoever believes in Him should not perish... John 3:16 *
********** W. Paul Mills ********** http://Mills-USA.com/ **********/
John Hasler
> I believe 'dpkg --purge <package>' does this also.
No. That removes package and all it's configuration files, which --remove
leaves in place.
--
John Hasler You may treat this work as if it
jo...@dhh.gt.org were in the public domain.
Dancing Horse Hill I waive all rights.
Elmwood, Wisconsin
Joey Hess
> I have been using apt and dselect for some time. Can any body tell me
> about the advantages/disadvantages of dselect and aptitude? and which is
> better?
Nine reasons why you should be using aptitude instead of apt-get or dselect.
1. aptitude can look just like apt-get
If you run 'aptitude update' or 'aptitude upgrade' or 'aptitude
install', it looks and works just like apt-get, with a few enhancements.
So there is no learning curve.
(If you're a dselect user, learning curve is obviously not one of your
problems.)
2. aptitude tracks automatically installed packages
Stop worrying about pruning unused libraries and support packages from
your system. If you use aptitude to install everything, it will keep
track of what packages are pulled in by dependencies alone, and remove
those packages when they are no longer needed.
3. aptitude sanely handles recommends
A long-standing failure of apt-get has been its lack of support for
the Recommends relationship. Which is a problem because many packages
in Debian rely on Recommends to pull in software that the average user
generally uses with the package. This is a not uncommon cause of
trouble, even though apt-get recently became able to at least mention
recommended packages, it's easy to miss its warnings.
Aptitude supports Recommends by default, and can be confgigured to
support Suggests too. It even supports installing recommended packages
when used in command-line mode.
4. use aptitude as a normal user and avoid hosing your system
Maybe you didn't know that you can run aptitude in gui mode as a regular
user. Make any changes you'd like to try out. If you get into a real
mess, you can hit 'q' and exit, your changes will not be saved.
(Aptitude also lets you use ctrl-u to undo changes.) Since it's running
as a normal user, you cannot hose your system until you tell aptitude to
do something, at which point it will prompt you for your root password.
5. aptitude has a powerful UI and searching capabilities
Between aptitude's categorical browser and its great support for
mutt-style filtering and searching of packages by name, description,
maintainer, dependencies, etc, you should be able to find packages
faster than ever before using aptitude.
6. aptitude makes it easy to keep track of obsolete software
If Debian stops distributing a package, apt will leave it on your system
indefinitly, with no warnings, and no upgrades. Aptitude lists such
packages in its "Obsolete and Locally Created Packages" section, so you
can be informed of the problem and do something about it.
7. aptitude has an interface to the Debian task system
Aptitude lets you use Debian's task system as it was designed to be
used. You can browse the available tasks, select a task for install, and
then dig into it and de-select parts of the task that you don't want.
apt-get has no support for tasks, and aptitude is better even than
special purpose tools like tasksel.
8. aptitude supports multiple sources
If your sources.list is configured to make multiple versions of a
package available, aptitude lets you drill down to see the available
versions and pick a non-default version to install. If a package breaks
in unstable, just roll it back to the version in testing.
9. aptitude logs its actions
Aptitude logs package it installs, upgrades, and removes to
/varlog/aptitude, which can be useful to work out why things started
breaking after yesterday's upgrade, or when you removed a partiticlar
package.
--
see shy jo
Clive Menzies
This is very useful. I've been using aptitude for a while (moved from
dselect, which I was reasonably happy with) and found it better than
dselect for reasons I found difficult to articulate. Not only have you
articulated all the reasons I like it but highlighted features I haven't
yet discovered ;)
Regards
Clive
--
http://www.clivemenzies.co.uk
strategies for business
Michael D Schleif
I would have been using aptitude long ago, _except_ for this hurdle on
my systems:
# sudo aptitude -P upgrade
Password:
Reading Package Lists... Done
Building Dependency Tree
Reading extended state information... Done
The following packages are unused and will be REMOVED:
antiword debiandoc-sgml debiandoc-sgml-doc debsums dhelp djbdns-doc
djtools doc-html-w3 docbook docbook-defguide docbook-doc docbook-dsssl
docbook-dsssl-doc docbook-mathml docbook-xsl emacs20-el esound foo2zjs
foomatic-db foomatic-db-engine foomatic-db-gimp-print foomatic-db-hpijs
foomatic-filters foomatic-gui fortune-mod fortunes-min freefont
freetype1-tools fttools gimp gimp-perl gimpprint-doc gimpprint-locales
gnome-doc-tools gnome-vfs-extras2 hpijs html2ps ijsgimpprint imlib-progs
irb jade jadetex karbon kchart kformula kivio koffice koshell kpresenter
kspread kugar kword libdv-bin libdv2 libgimp1.2 libgtkxmhtml1
libjcode-pm-perl libmpeg1 libpng10-dev libpng2-dev libreadline-ruby
librecode0 libroman-perl libsgmls-perl libsp1 libterm-readkey-perl
libtext-format-perl libtiff-tools linuxdoc-tools linuxdoc-tools-info
linuxdoc-tools-latex linuxdoc-tools-text man2html manpages-dev netcat
netpbm-nonfree opensp pchar pdl perlmagick perlsgml pgperl pgplot5 psgml
python-glade2 python-gnome2 python-optik python-xml python2.2-glade2
python2.2-gnome2 python2.2-gtk2 python2.2-optik python2.2-pyorbit
python2.2-xml python2.2-xmlbase recode reportbug ruby-examples
sgml-base-doc sgmls-doc sgmlspl sp spell swish++ t1utils transfig
ttf-arphic-bkai00mp ttf-arphic-bsmi00lp ttf-arphic-gbsn00lp
ttf-arphic-gkai00mp ttf-xtt-wadalab-gothic ttf-xtt-watanabe-mincho
ttmkfdir type1inst w3-dtd-mathml w3-recs w3-recs-2002 w3-recs-2003
w3c-dtd-xhtml xfig xfig-doc xpdf-utils xscreensaver-gnome
The following packages have been kept back:
bastille x-window-system-core
The following packages will be upgraded:
arts dictionaries-common fontconfig gnome-vlc kernel-package libarts1
libartsc0 libdevmapper1.00 libfontconfig1 libfontconfig1-dev
libhtml-parser-perl libxml2 libxslt1.1 links mozilla-plugin-vlc ntp
ntp-doc ntp-server ntp-simple ntpdate proftpd proftpd-common
python2.3-gnome2 scsitools ssh synaptic ucf vlc vlc-plugin-esd xmms
30 packages upgraded, 0 newly installed, 123 to remove and 2 not upgraded.
Need to get 14.5MB of archives. After unpacking 342MB will be freed.
*HOW* should I get around *ALL* of those REMOVED's ???
--
Best Regards,
mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know. The more I know, the more I know I don't know . . .
--
Nori Heikkinen
> J.S.Sahambi wrote:
> > I have been using apt and dselect for some time. Can any body tell me
> > about the advantages/disadvantages of dselect and aptitude? and which is
> > better?
>
> Nine reasons why you should be using aptitude instead of apt-get or dselect.
>
> 1. aptitude can look just like apt-get
and the number 10 reason why you should be using aptitude instead of
apt-get ...:
10. you can play minesweeper if you get bored/frustrated!
</nori>
--
.~. nori @ sccs.swarthmore.edu
/V\ http://www.sccs.swarthmore.edu/~nori/jnl/
// \\ @ maenad.net
/( )\ www.maenad.net
^`~'^
Joey Hess
> The following packages have been kept back:
> bastille x-window-system-core
> The following packages will be upgraded:
> arts dictionaries-common fontconfig gnome-vlc kernel-package libarts1
> libartsc0 libdevmapper1.00 libfontconfig1 libfontconfig1-dev
> libhtml-parser-perl libxml2 libxslt1.1 links mozilla-plugin-vlc ntp
> ntp-doc ntp-server ntp-simple ntpdate proftpd proftpd-common
> python2.3-gnome2 scsitools ssh synaptic ucf vlc vlc-plugin-esd xmms
> 30 packages upgraded, 0 newly installed, 123 to remove and 2 not upgraded.
> Need to get 14.5MB of archives. After unpacking 342MB will be freed.
>
>
> *HOW* should I get around *ALL* of those REMOVED's ???
I'd probably try a dist-upgrade first, in case that helped. If not,
I'd type 'e' at the prompt to go to interactive mode and see why it
wants to remove some of the packages, and tell it how to resolve
whatever jam it's in.
--
see shy jo
Monique Y. Mudama
>
> I would have been using aptitude long ago, _except_ for this hurdle on
> my systems:
>
> # sudo aptitude -P upgrade
> Password:
> Reading Package Lists... Done
> Reading extended state information... Done
I think this is the relevant part:
> The following packages are unused and will be REMOVED:
Do you have this line in ~/.aptitude/config
aptitude::Delete-Unused "true";
?
Search for "TRACKING UNUSED PACKAGES" in /usr/share/doc/aptitude/README
for more details.
--
monique
Michael D Schleif
> On 2004-04-21, Michael D Schleif penned:
> >
> > I would have been using aptitude long ago, _except_ for this hurdle on
> > my systems:
> >
> > # sudo aptitude -P upgrade
> > Password:
> > Reading Package Lists... Done
> > Building Dependency Tree =20
> > Reading extended state information... Done
>
>
> I think this is the relevant part:
>
> > The following packages are unused and will be REMOVED:
>
> Do you have this line in ~/.aptitude/config
>
> aptitude::Delete-Unused "true";
>
> ?
Yes, indeed, that is it! Thank you.
> Search for "TRACKING UNUSED PACKAGES" in /usr/share/doc/aptitude/README
> for more details.
Although, I found `unused' and other information in that file, `TRACKING
UNUSED PACKAGES' is not in my file. What version of aptitude are you
running?
Thank you, again, for your consideration.
Monique Y. Mudama
>
>
>> Search for "TRACKING UNUSED PACKAGES" in /usr/share/doc/aptitude/README
>> for more details.
>
> Although, I found `unused' and other information in that file, `TRACKING
> UNUSED PACKAGES' is not in my file. What version of aptitude are you
> running?
This was from an unstable system ...
aptitude version: 0.2.14.1-2
> Thank you, again, for your consideration.
I've been sitting on your message for a while, planning to see if I
could answer it "eventually." I'm glad I finally got around to
investigating =)
Jules Dubois
22:27:12 -0400, Joey Hess wrote:
> Nine reasons why you should be using aptitude instead of apt-get or
> dselect.
> [snip]
I keep hearing about the advantages of aptitude (over, for example,
Synaptic), but your article, Mr. Hess, was excellent. I gave aptitude
another try last night and most of my earlier problems with it are gone.
Libranet decided a few months ago to modify my sources.list to use
unstable instead of testing. I'm now finding there are about 50 packages
I can't upgrade because of unsatisfied dependencies.
aptitude shows these packages as 'Broken' so I've changed their status to
'Hold' because I want to keep them.
I hope you'll consider these questions.
1) If I don't want to remove packages simply because the upgrade
path is currently broken, is it safe to remove the 'Hold' and leave
them as 'Broken'?
2) If I can find some combination of packages which resolves the
unsatisfied-dependency conditions, is it safe to install these?
By 'safe' above, I mean only 'my system won't die a horrible, flaming
death', not 'the packages are completely secure and bug-free'.
Katipo
> Libranet decided a few months ago to modify my sources.list to
> useunstable instead of testing. I'm now finding there are about 50
> packages
>
> I can't upgrade because of unsatisfied dependencies.
>
Hello Jules,
I had the same problem, I've got Libranet 2.8.1 installed.
When the Debian server compromise happened, Libranet installed their own
mirror site.
They then upgraded the adminmenu package to suit.
Their seems to have been some sort of communication breakdown somewhere
along the line,
because upon investigation of an error message from an install, I found
a new /etc/apt.sources.list
that included uncommented lines, not just from unstable, but from
experimental as well.
The answer to the situation, if it hasn't already proceeded too far,
would be to go into your list, and comment out
everything except stable and sarge, which will give you back the config
for the standard Libranet system,
and then attempt to roll back to previously installed versions of your
problem packages.
How I did it was to revert to the original adminmenu, and placed that
package on hold.
It's a very useful package for a newby, and one of the principle reasons
I advocate Libranet as an ideal route to take for a newby,
but I'm migrating to Debian sarge now, and just using Libranet for
configuration exercises.
Past a certain stage, it's just too restrictive. Adminmenu depends on
apparently totally unrelated packages like kudzu and yelp, for example,
so you're restricted as far as configuring your own system.
Asking more accurate questions might have helped you earlier also, I
think that this is the first time you have mentioned you are running
Libranet?
Regards,
David.
Jules Dubois
+0800, Katipo wrote:
> Jules Dubois wrote:
>
>> Libranet decided a few months ago to modify my sources.list to
>> use unstable instead of testing.
>>
> When the Debian server compromise happened, Libranet installed their own
> mirror site.
> They then upgraded the adminmenu package to suit.
The official explanation is that some Debian packages don't work properly
on Libranet systems, so they created a "cedar" release. The thing I
really didn't like was the message that I must "install a new sources.list
file" without any explanation of the major changes they had in mind.
Of course, this isn't a Debian problem.
> [...]
> a new /etc/apt.sources.list
> that included uncommented lines, not just from unstable, but from
> experimental as well.
stable, testing, unstable, snapshot, and experimental, all without warning.
> The answer to the situation, if it hasn't already proceeded too far,
My system works fine and, although there are packages marked upgradable
(but I can't upgrade), there's nothing I need that I don't already have.
It's just I'd rather not look through the same set of packages every time
I update.
> would be to go into your list, and comment out
> everything except stable and sarge
I don't mind running unstable. I don't understand the meaning
of 'experimental' and 'snapshot' and they concern me a little. Also, I've
read several messages saying the best choices were 'stable' and
'unstable'.
> How I did it was to revert to the original adminmenu, and placed that
> package on hold.
I'd like to purge adminmenu and libranet-upgrade because I stopped using
them months ago.
> It's a very useful package for a newby [...]
I liked the way it set up X and GDM for me when I installed it.
> I think that this
> is the first time you have mentioned you are running Libranet?
I think it is but I don't remember asking questions, previously, about how
to switch from Synaptic to Aptitude. I experimented a bit and discovered
that if I remove the "hold" from the "broken" packages, almost all of them
revert back to "hold" when I restart aptitude (with the exception of WINE.)
I still have this question:
If I can find some combination of installable or upgradable packages which
removes a "broken" condition, can I just go ahead and install them? (I
must have a reliable system for the next three weeks or so and then I can
break it.)
Richard Lyons
[...]
> I still have this question:
>
> If I can find some combination of installable or upgradable packages
> which removes a "broken" condition, can I just go ahead and install
> them? (I must have a reliable system for the next three weeks or so
> and then I can break it.)
I hope the answer to this is going to be yes -- because that is what I
always do...
--
richard
Katipo
>I still have this question:
>
>If I can find some combination of installable or upgradable packages which
>removes a "broken" condition, can I just go ahead and install them? (I
>must have a reliable system for the next three weeks or so and then I can
>break it.)
>
>
I think the immediate requirement is to go into your sources list and comment out all those unwanted lines.
The thing that woke me up was the packet managers' advice concerning an 'inconsistant variation', or something to that effect.
First thing:- stabilise your system.
Comment out snapshot and experimental as well. Experimental is still being built, one stage ahead of Sid.
Snapshot consists of every package that was ever made, or that's my impression. If you don't limit your input, you are going to get flooded.
Next I would remove the Libranet adminmenu upgrade package, and place adminmenu itself on hold.
Keep the Libranet entries, along with the stable and sarge, making sure that the 'src' entries are also commented out, leaving only the deb entries open.
Then I would start removing broken packages and reinstalling them.
As long as they are not essential packages, this should, by my estimation of the system, give you back the system you started with.
Regards,
David.
Jules Dubois
23:52:52 +0800, Katipo wrote:
Thank you for your comments. I'm can see I've not been very clear in my
previous messages. I'll try again.
> Jules Dubois wrote:
>
>>If I can find some combination of installable or upgradable packages
>>which removes a "broken" condition, can I just go ahead and install
>>them?
>>
> I think the immediate requirement is to go into your sources list and
> comment out all those unwanted lines. The thing that woke me up was the
> packet managers' advice concerning an 'inconsistant variation', or
> something to that effect.
I've had non-upgradable packages in the past, when I was running
'testing', such as when updated packages from big suites like KDE began
appearing there. I can't discern any ill effects from the situation.
> First thing:- stabilise your system.
My system is stable (i.e., working as expected). Nothing that's actually
installed on my system is broken (i.e., marked by Aptitude, Synaptic, or
apt-get as having dependency problems).
> Comment out snapshot and experimental as well.
I think I will do this.
> Next I would remove the Libranet adminmenu upgrade package, and place
> adminmenu itself on hold.
Why do I want to keep either package? I don't use them.
> Keep the Libranet entries, along with the stable and sarge,
What's wrong with unstable? I know I've read several convincing messages
saying the best choices are 'stable' and 'unstable' but, as usual, I
remember the conclusion and not the rationale.
> Then I would start removing broken packages and reinstalling them.
(I can see the lack of clarity in my previous messages.) My system's
status is:
1) No package as installed on my system is broken.
2) I don't require any upgrades.
However,
1) Some packages which I've installed are listed as 'upgradable'.
I have older versions and newer versions are available.
2) The new versions of these packages have dependencies which conflict
with the dependencies of some other packages I have installed.
3) Aptitude labels these packages, if I remove the 'hold', as 'broken'.
It seems to consider brokenness to apply to the upgrades, not my system
as it currently stands. I find this to be reasonable behavior.
4) Synaptic doesn't list these packages as broken but it won't allow me to
upgrade them. I find this to be reasonable behavior.
However, this means I have to
(a) wait for someone else to resolve these conflicts, giving me a
consistent set of upgrades; or
(b) resolve those conflicts, manually, to the extent I'm able to do so; or
(c) both of the above.
I really don't have any problems. I'm just seeking some advice on how to
proceed, probably sticking with 'unstable'.
--
"[Linux kernel v2.6 has] enterprise-level performance: you see 32-way
multiprocessor SMP configurations, 128-way NUMA configurations, high
degrees of reliability."
-- Darl McBride. CEO, The SCO Group. Harvard University lecture. 2/2/2004.
Jules Dubois
10:44:48 +0200, Richard Lyons wrote:
> On Sunday 25 April 2004 10:07, Jules Dubois wrote:
>> [...]
>> If I can find some combination of installable or upgradable packages
>> which removes a "broken" condition, can I just go ahead and install
>> them?
>
> I hope the answer to this is going to be yes -- because that is what I
> always do...
It seems like a reasonable and proper course of action. Can I assume,
from your lack of warning, you haven't found it harmful to do so?
Katipo
Jules Dubois wrote:
>In article <408BDED4...@weavers-web.org>, on Sun, 25 Apr 2004
>23:52:52 +0800, Katipo wrote:
>
>Thank you for your comments. I'm can see I've not been very clear in my
>previous messages. I'll try again.
>
>
>
>>Jules Dubois wrote:
>>
>>
>>
>>>If I can find some combination of installable or upgradable packages
>>>which removes a "broken" condition, can I just go ahead and install
>>>them?
>>>
>>>
Yes.
Sometimes you are better of removing a broken package, and then
reinstalling it.
My impression was that you were looking at a potentially broken system,
and thought that the appropriate response was damage control.
>>>
>>>
>>I think the immediate requirement is to go into your sources list and
>>comment out all those unwanted lines. The thing that woke me up was the
>>packet managers' advice concerning an 'inconsistant variation', or
>>something to that effect.
>>
>>
>
>I've had non-upgradable packages in the past, when I was running
>'testing', such as when updated packages from big suites like KDE began
>appearing there. I can't discern any ill effects from the situation.
>
>
>
>>First thing:- stabilise your system.
>>
>>
>
>My system is stable (i.e., working as expected). Nothing that's actually
>installed on my system is broken (i.e., marked by Aptitude, Synaptic, or
>apt-get as having dependency problems).
>
>
>
>>Comment out snapshot and experimental as well.
>>
>>
>
>I think I will do this.
>
>
>
>>Next I would remove the Libranet adminmenu upgrade package, and place
>>adminmenu itself on hold.
>>
>>
>
>Why do I want to keep either package? I don't use them.
>
>
Because you say you need a stable system for the next three weeks, and
if you start to play, you might not have that.
It all depends on your definition of the terminology 'need', I suppose.
>
>
>>Keep the Libranet entries, along with the stable and sarge,
>>
>>
>
>What's wrong with unstable? I know I've read several convincing messages
>saying the best choices are 'stable' and 'unstable' but, as usual, I
>remember the conclusion and not the rationale.
>
>
Nothing wrong with unstable.
It's where I'm heading.
But it's too late to shut the stable door, once the horse has bolted.
How important are the next three weeks?
>
>
>>Then I would start removing broken packages and reinstalling them.
>>
>>
>
>(I can see the lack of clarity in my previous messages.) My system's
>status is:
>
>1) No package as installed on my system is broken.
>
>2) I don't require any upgrades.
>
>However,
>
>1) Some packages which I've installed are listed as 'upgradable'.
> I have older versions and newer versions are available.
>
>
Comment out all unwanted apt/ sources.list entries before you do so.
>2) The new versions of these packages have dependencies which conflict
> with the dependencies of some other packages I have installed.
>
>
In some circumstances this will not be a problem. Your package manager
will simply remove the old dependencies, replacing them with the new
equivalents.
In other circumstances, where you have a number of different release
entries open in your sources list, this will turn you into somebody who
works in the night time entertainment industry.
>3) Aptitude labels these packages, if I remove the 'hold', as 'broken'.
> It seems to consider brokenness to apply to the upgrades, not my system
> as it currently stands. I find this to be reasonable behavior.
>
>
Yes.
>4) Synaptic doesn't list these packages as broken but it won't allow me to
> upgrade them. I find this to be reasonable behavior.
>
>However, this means I have to
>
>(a) wait for someone else to resolve these conflicts, giving me a
> consistent set of upgrades; or
>
>(b) resolve those conflicts, manually, to the extent I'm able to do so; or
>
>(c) both of the above.
>
>I really don't have any problems. I'm just seeking some advice on how to
>proceed, probably sticking with 'unstable'.
>
>
Make the process gradual.
Get yourself a full Sarge system first, and after that go to Sid.
Regards,
David.
Jules Dubois
21:11:48 +0800, Katipo wrote:
> Jules Dubois wrote:
>
> My impression was that you were looking at a potentially broken system,
> and thought that the appropriate response was damage control.
I finally realized that and attempted to actually be clear about what I
was saying and asking.
> 1) Some packages which I've installed are listed as 'upgradable'.
>> I have older versions and newer versions are available.
>>
>>
> Comment out all unwanted apt/ sources.list entries before you do so.
Done. I now have only Debian Woody and Sid and Libranet Cedar left. I
also discovered that netselect-apt was no longer installed on my system
but the package was in the cache. I don't know how that could have
happened.
> Nothing wrong with unstable.
> It's where I'm heading.
> But it's too late to shut the stable door, once the horse has bolted.
> How important are the next three weeks?
I have a project I must finish but I was overoptimistic. I don't have
three weeks; I have eight days.
> Get yourself a full Sarge system first, and after that go to Sid.
I had a Sarge system before it changed.
Libranet had me updating from Woody, Sarge, Sid, experimental, a snapshot,
and Libranet itself. I don't know what I could call this combination but
fortunately I never had a non-functional system.
Thanks.