Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Package/Packaging Rant

Here you can discuss every aspect of Debian. Note: not for support requests!
Post Reply
Message
Author
stoaphil
Posts: 14
Joined: 2013-08-08 23:53

Package/Packaging Rant

#1 Post by stoaphil »

Hi all:

I'll save everyone some time and announce upfront that this is mainly a rant, which is why it's posted here and not in the questions sections. However, if you are inclined to read further and offer some pearls of wisdom, they would not go to waste.

My concerns are with packaging and package management, and I presently have three issues:


1. Last summer, I wanted to install jessie on an old Pentium4 to use for some 32-bit programming. I like the "codeblocks" IDE. So I checked the repository[1] and lo and behold, codeblocks is available for wheezy, stretch, and sid, but only as a backport for jessie. Apparently, the latest version of codeblocks (13.12) has been in testing for about 2 years (1-21-14).[2] A most generous interpretation puts it in testing since last September. After waiting for about a month for it to come out of testing, I decided to install stretch, where codeblocks was available, which I did.

So rant #1 is: is this how "testing" in Debian is supposed to work? I'm assuming it is different than say, Arch Linux, where something hits testing and is generally released for use within a day or maybe a week. Perpetual testing? Who is doing the "testing"?


2. Stretch is working fine for a few months, so I decided to install my favourite GUI text editor, "juffed." Whoa! No juffed in stretch.[3] There is a juffed in squeeze, wheezy, sid, and experimental, just not jessie or stretch!

So, rant #2 is: the same major version of juffed (0.8.1-1) is in squeeze, wheezy, and sid. Is there a valid packaging reason why this is not in stretch (testing)?


3. Yesterday I decided to take a break from the hum-drum of dwm and play with i3. As this install only has xorg and a few graphical applications (no desktop environment, java, etc.), I wasn't expecting any conflict issues. Wrong again. A quick

Code: Select all

aptitude install i3
returned some dependency conflicts for which it (aptitude) recommended the removal of 138 packages and the ignoring of 40 other conflicts. I'll spare all the gory details, but here is a taste:
The following actions will resolve these dependencies:
Remove the following packages:
...
106) xorg
107) xserver-xorg
108) xserver-xorg-core
109) xserver-xorg-input-all
110) xserver-xorg-input-evdev
111) xserver-xorg-input-mouse
112) xserver-xorg-input-synaptics
113) xserver-xorg-input-vmmouse
114) xserver-xorg-input-wacom
115) xserver-xorg-video-all
116) xserver-xorg-video-ati
117) xserver-xorg-video-cirrus
118) xserver-xorg-video-fbdev
119) xserver-xorg-video-geode
120) xserver-xorg-video-intel
121) xserver-xorg-video-mach64
122) xserver-xorg-video-mga
123) xserver-xorg-video-modesetting
124) xserver-xorg-video-neomagic
125) xserver-xorg-video-nouveau
126) xserver-xorg-video-openchrome
127) xserver-xorg-video-qxl
128) xserver-xorg-video-r128
129) xserver-xorg-video-radeon
130) xserver-xorg-video-savage
131) xserver-xorg-video-siliconmotion
132) xserver-xorg-video-sisusb
133) xserver-xorg-video-tdfx
134) xserver-xorg-video-trident
135) xserver-xorg-video-vesa
136) xserver-xorg-video-vmware
....

Yes, I was advised to remove xorg-server and all drivers, etc., in order to install an x-window manager!

Rant #3: this seems like one of those situations where one little semi-colon is out of place and once fixed, all falls into place again. However, I wasn't able to find an answer on these boards or the interwebz in general. (PS - no, I haven't been dancing to the "repo mix-and-match hit parade," my sources.list is how it was provided by the installation.) This is a stock install with a few applications on top. No funny-stuff. This is not the first time
I have received this laundry-list of conflicts; it occurrs regularly.

If you've actually read the foregoing, thanks for listening!


[1] https://packages.debian.org/search?keywords=codeblocks
[2] https://tracker.debian.org/pkg/codeblocks
[3] https://packages.debian.org/search?keywords=juffed

User avatar
dilberts_left_nut
Administrator
Administrator
Posts: 5346
Joined: 2009-10-05 07:54
Location: enzed
Has thanked: 12 times
Been thanked: 66 times

Re: Package/Packaging Rant

#2 Post by dilberts_left_nut »

stoaphil wrote:So rant #1 is: is this how "testing" in Debian is supposed to work? I'm assuming it is different than say, Arch Linux, where something hits testing and is generally released for use within a day or maybe a week. Perpetual testing? Who is doing the "testing"?
Yes.
The primary function of Debian is to produce the 'stable' release, which happens roughly every two years. This release then does not change (much - i.e. security fixes, no new versions, that's what backports is for).
https://www.debian.org/doc/manuals/debi ... l#s-stable

Testing is where the next stable is built (and tested by whoever wants to use 'testing').

Packages flow from sid to testing when they meet the criteria.
https://www.debian.org/doc/manuals/debi ... #s-testing

Packages do not flow from testing to stable (except all at once, at release, when testing becomes 'stable', and the previous stable becomes 'oldstable').
stoaphil wrote:So, rant #2 is: the same major version of juffed (0.8.1-1) is in squeeze, wheezy, and sid. Is there a valid packaging reason why this is not in stretch (testing)?
https://packages.qa.debian.org/j/juffed.html
stoaphil wrote:Yes, I was advised to remove xorg-server and all drivers, etc., in order to install an x-window manager!

Rant #3: this seems like one of those situations where one little semi-colon is out of place and once fixed, all falls into place again.
A typo (bug) in the i3 package is unlikely - It's much more likely to be a conflict/alternative choice somewhere in the list that is a dependency of a metapackage which is holding all that (including xorg) on your system.
Aptitude has a more complex dependency resolver than apt-get, which is usually an advantage, but can throw up some strange results as the 'first hit' (especially for things that touch a lot of packages) - did you say no to that and look at the next solution?
AdrianTM wrote:There's no hacker in my grandma...

spacex
Posts: 637
Joined: 2015-01-17 01:27

Re: Package/Packaging Rant

#3 Post by spacex »

Yes, and because Jessie was released prematurely, there was quite a few packages that din't make the cut off date, and therefore you will not see them in stable, until Stretch becomes the new stable. But rest assure, then there will be other packages that didn't make the cut off date. That's why it's not uncommon that a package exists in all branches, except the stable branch. So you better learn how to use backports if you are going to use stable :)

stoaphil
Posts: 14
Joined: 2013-08-08 23:53

Re: Package/Packaging Rant

#4 Post by stoaphil »

Thanks to d_l_n and spacex for your explanations.
A typo (bug) in the i3 package is unlikely - It's much more likely to be a conflict/alternative choice somewhere in the list that is a dependency of a metapackage which is holding all that (including xorg) on your system.
Aptitude has a more complex dependency resolver than apt-get, which is usually an advantage, but can throw up some strange results as the 'first hit' (especially for things that touch a lot of packages) - did you say no to that and look at the next solution?
I was very unclear on what I meant by a small, easily-fixed glitch. I wasn't speaking of something with the i3 package (which likely would have shown up on the boards by now) but some small impropriety in my system. Sorry for the confusion.

Yes, I did try at least three of aptitude's proposed solutions, but each proposed removing about one-half of my applications, so no solution there. You are also correct as to aptitude's dependency resolver; if I were to use apt-get, it would install without dependency issues. However, even apt-get seems to be a bit "confused":

Code: Select all

dutch@debian:~ $ sudo apt-get install i3
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following package was automatically installed and is no longer required:
  linux-image-3.16.0-4-686-pae
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
  dunst i3-wm i3lock i3status libalgorithm-diff-xs-perl libanyevent-i3-perl libanyevent-perl libasync-interrupt-perl libb-hooks-op-check-perl libbareword-filehandles-perl
  libclass-c3-xs-perl libclass-xsaccessor-perl libcommon-sense-perl libconfuse-common libconfuse0 libdevel-caller-perl libdevel-lexalias-perl libev-perl libev4 libfcgi-perl
  libfile-fcntllock-perl libguard-perl libhtml-parser-perl libindirect-perl libiw30 libjson-xs-perl liblexical-sealrequirehints-perl liblist-moreutils-perl
  liblocale-gettext-perl libmultidimensional-perl libnet-ssleay-perl libpackage-stash-xs-perl libpadwalker-perl libparams-classify-perl libparams-util-perl
  libparams-validate-perl libperl5.22 libsnmp30 libsub-identify-perl libsub-name-perl libtext-charwidth-perl libtext-iconv-perl libtext-soundex-perl libtype-tiny-xs-perl
  libtypes-serialiser-perl libunicode-utf8-perl libvariable-magic-perl libxcb-cursor0 libxcb-dpms0 libxcb-xinerama0 libxdg-basedir1 libxml-libxml-perl libxml-parser-perl
  libyajl2 perl perl-base perl-modules-5.22 rxvt-unicode
Suggested packages:
  libevent-perl libio-async-perl libpoe-perl libtask-weaken-perl libdata-dump-perl libscalar-number-perl perl-doc libterm-readline-gnu-perl | libterm-readline-perl-perl
The following packages will be REMOVED:
  libperl5.20 perl-modules
The following NEW packages will be installed:
  dunst i3 i3-wm i3lock i3status libanyevent-i3-perl libanyevent-perl libasync-interrupt-perl libcommon-sense-perl libconfuse-common libconfuse0 libev-perl libev4
  libguard-perl libiw30 libjson-xs-perl libperl5.22 libtypes-serialiser-perl libxcb-cursor0 libxcb-dpms0 libxcb-xinerama0 libxdg-basedir1 libyajl2 perl-modules-5.22
The following packages will be upgraded:
  libalgorithm-diff-xs-perl libb-hooks-op-check-perl libbareword-filehandles-perl libclass-c3-xs-perl libclass-xsaccessor-perl libdevel-caller-perl libdevel-lexalias-perl
  libfcgi-perl libfile-fcntllock-perl libhtml-parser-perl libindirect-perl liblexical-sealrequirehints-perl liblist-moreutils-perl liblocale-gettext-perl
  libmultidimensional-perl libnet-ssleay-perl libpackage-stash-xs-perl libpadwalker-perl libparams-classify-perl libparams-util-perl libparams-validate-perl libsnmp30
  libsub-identify-perl libsub-name-perl libtext-charwidth-perl libtext-iconv-perl libtext-soundex-perl libtype-tiny-xs-perl libunicode-utf8-perl libvariable-magic-perl
  libxml-libxml-perl libxml-parser-perl perl perl-base rxvt-unicode
35 upgraded, 24 newly installed, 2 to remove and 36 not upgraded.
Need to get 13.7 MB of archives.
After this operation, 12.2 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
dutch@debian:~ $
You'll notice the last entry under "The following additional packages will be installed:" is rxvt-unicode; that package is also the last entry under "The following packages will be upgraded:" However, I already have a current version of rxvt-unicode installed:

Code: Select all

dutch@debian:~ $ aptitude show rxvt-unicode
Package: rxvt-unicode                    
State: installed
Automatically installed: no
Version: 9.21-1
I'm not sure why apt-get wants to install, then upgrade, a package that is already installed and up-to-date. In any event, I find mixing apt-get and aptitude only slightly less of an egregious action that mixing repos. (Short backstory - a couple of years ago I ran testing and the system failed miserably when maintained with apt-get; this time, I only upgrade with aptitude's "safe-upgrade" and the system has been very stable.)

Thanks again.

User avatar
dilberts_left_nut
Administrator
Administrator
Posts: 5346
Joined: 2009-10-05 07:54
Location: enzed
Has thanked: 12 times
Been thanked: 66 times

Re: Package/Packaging Rant

#5 Post by dilberts_left_nut »

The fact that autoremove wants to get rid of your kernel raises a red flag about the current state of your system. Presumably you have done something to remove the kernel metapackage, but not marked the kernel as manually installed?

I like the aptitude interface for sorting out confusing apt actions - you can toggle packages on and off and see what would happen, which can help narrow down where the issues are a lot more quickly than trying to devine it from a wall of output.
AdrianTM wrote:There's no hacker in my grandma...

User avatar
fireExit
Posts: 559
Joined: 2014-11-20 11:22

Re: Package/Packaging Rant

#6 Post by fireExit »

stoaphil wrote: (PS - no, I haven't been dancing to the "repo mix-and-match hit parade," my sources.list is how it was provided by the installation.) This is a stock install with a few applications on top. No funny-stuff. This is not the first time
I have received this laundry-list of conflicts; it occurrs regularly.
this is not true
stoaphil wrote:The following additional packages will be installed:
  dunst i3-wm i3lock i3status libalgorithm-diff-xs-perl libanyevent-i3-perl libanyevent-perl libasync-interrupt-perl libb-hooks-op-check-perl libbareword-filehandles-perl
  libclass-c3-xs-perl libclass-xsaccessor-perl libcommon-sense-perl libconfuse-common libconfuse0 libdevel-caller-perl libdevel-lexalias-perl libev-perl libev4 libfcgi-perl
  libfile-fcntllock-perl libguard-perl libhtml-parser-perl libindirect-perl libiw30 libjson-xs-perl liblexical-sealrequirehints-perl liblist-moreutils-perl
  liblocale-gettext-perl libmultidimensional-perl libnet-ssleay-perl libpackage-stash-xs-perl libpadwalker-perl libparams-classify-perl libparams-util-perl
  libparams-validate-perl libperl5.22 libsnmp30 libsub-identify-perl libsub-name-perl libtext-charwidth-perl libtext-iconv-perl libtext-soundex-perl libtype-tiny-xs-perl
  libtypes-serialiser-perl libunicode-utf8-perl libvariable-magic-perl libxcb-cursor0 libxcb-dpms0 libxcb-xinerama0 libxdg-basedir1 libxml-libxml-perl libxml-parser-perl
  libyajl2 perl perl-base perl-modules-5.22 rxvt-unicode
perl5.22 is not available in jessie https://packages.debian.org/source/stretch/perl
EDIT: and
https://packages.debian.org/search?keyw ... ection=all

stoaphil
Posts: 14
Joined: 2013-08-08 23:53

Re: Package/Packaging Rant

#7 Post by stoaphil »

dilberts_left_nut wrote:
The fact that autoremove wants to get rid of your kernel raises a red flag about the current state of your system. Presumably you have done something to remove the kernel metapackage, but not marked the kernel as manually installed?
I've done nothing to this system that the commands "aptitude update," "aptitude safe-upgrade," or "aptitude install XYZ" haven't done on their own. I really haven't used this install at all - as noted above, I had some issues with testing before so I've simply been firing it up once a week or so and updating it to see how stable it is.

fireExit: I'm not running jessie, I'm running testing:

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 71 times

Re: Package/Packaging Rant

#8 Post by stevepusser »

I'm sorry--I don't understand why you decided to run testing instead of simply installing codeblocks on Jessie from the jessie-backports repository.
MX Linux packager and developer

User avatar
fireExit
Posts: 559
Joined: 2014-11-20 11:22

Re: Package/Packaging Rant

#9 Post by fireExit »

yes, you are! i misread (your clearly long) OP :)

with testing and/or sid i always use dist-upgrade/full-upgrade (when possible, otherwise i will wait a day or two or a week, depending on the complexity of the transition);

this way i know that
1. transitions are managed the way the maintainers intended they to be;
2. obsolete package(s) are removed and at the same time new packages (and new dependencies) are correctly installed;
[this will make the system ever-changing and unreliable (library foo might suddenly disappear or a whole sub-system change into something you didn't expect and want) but that's what testing/sid is all about (if you want frozen stability, run stable)]

you have a working example of the difference between safe-upgrade and full-upgrade in the output that you shared above:
we transitioned from perl5.20 to perl5.22 (not an easy transition BTW) but you never did it in your system and now apt is trying to upgrade (clumsy) at the same time that installs i3 (due to its perl dependency)

this is the output in a full updated testing KDE

Code: Select all

  The following additional packages will be installed:
  dunst i3-wm i3lock i3status libanyevent-i3-perl libanyevent-perl libasync-interrupt-perl libcommon-sense-perl                   
  libconfuse-common libconfuse0 libev-perl libev4 libguard-perl libjson-xs-perl libtypes-serialiser-perl libxcb-xinerama0         
  libxdg-basedir1 suckless-tools                                                                                                  
Suggested packages:                                                                                                               
  libevent-perl libio-async-perl libpoe-perl libtask-weaken-perl dwm stterm surf                                                  
The following NEW packages will be installed:                                                                                     
  dunst i3 i3-wm i3lock i3status libanyevent-i3-perl libanyevent-perl libasync-interrupt-perl libcommon-sense-perl                
  libconfuse-common libconfuse0 libev-perl libev4 libguard-perl libjson-xs-perl libtypes-serialiser-perl libxcb-xinerama0         
  libxdg-basedir1 suckless-tools                                                                                                  
0 upgraded, 19 newly installed, 0 to remove and 0 not upgraded.                                                                   
Need to get 1,799 kB of archives.                                                                                                 
After this operation, 4,746 kB of additional disk space will be used.                                                             
Do you want to continue? [Y/n]     
it shouldn't be much different if your system was balanced to begin with.
Last edited by fireExit on 2016-01-05 02:32, edited 1 time in total.

User avatar
dilberts_left_nut
Administrator
Administrator
Posts: 5346
Joined: 2009-10-05 07:54
Location: enzed
Has thanked: 12 times
Been thanked: 66 times

Re: Package/Packaging Rant

#10 Post by dilberts_left_nut »

stoaphil wrote:fireExit: I'm not running jessie, I'm running testing
Well that goes a long way to explaining the wierdness - when using testing or sid you really must use 'full-upgrade' (or deprecated equvalent 'dist-upgrade') and NOT (only) 'safe-upgrade', as apt will tie itself in knots trying not to remove obsoleted packages and wont pull in the required new packages - you will just have a borked version of what 'testing' used to be...
AdrianTM wrote:There's no hacker in my grandma...

stoaphil
Posts: 14
Joined: 2013-08-08 23:53

Re: Package/Packaging Rant

#11 Post by stoaphil »

stevepusser wrote:
I'm sorry--I don't understand why you decided to run testing instead of simply installing codeblocks on Jessie from the jessie-backports repository.
That was a few months ago - I don't recall the exact thought process. I had two choices (three or four, actually, but I wasn't interested in sid or experimental); run a less-than-stable jessie with backports or a less-than-stable testing. For whatever reason, I chose testing.

stoaphil
Posts: 14
Joined: 2013-08-08 23:53

Re: Package/Packaging Rant

#12 Post by stoaphil »

dilberts_left_nut wrote:
...when using testing or sid you really must use 'full-upgrade' (or deprecated equvalent 'dist-upgrade') and NOT (only) 'safe-upgrade', as apt will tie itself in knots trying not to remove obsoleted packages and wont pull in the required new packages - you will just have a borked version of what 'testing' used to be...
I've never heard that before. The package management wiki[1] states "To make an update of all the changed packages, enter the line

Code: Select all

# aptitude safe-upgrade
It also indicates full-upgrade is to be used (at least once) when going from one major release to another (which isn't the case here), and states "[a] dist-upgrade may also be required to keep up-to-date with the latest versions of sid" (which isn't the case here). Nothing about this being the case for testing. Also, nothing in aptitude's man page describes limiting safe-upgrade to stable releases. Is there some documentation you are aware of that recommends this?

I'm not trying to be argumenative, as fireExit is advising the same full-upgrade procedure, but just explaining that the documentation I've read, and was following, didn't give any hints that breakage would occur if I used safe-upgrade on a testing machine.

Regardless, as noted a few times above, when I ran testing a couple of years ago, regularly using "apt-get dist-upgrade" caused frequent breakages, and I just got tired of fixing it, so I decided to try only safe-upgrade this time.

[1]https://wiki.debian.org/DebianPackageManagement

User avatar
dilberts_left_nut
Administrator
Administrator
Posts: 5346
Joined: 2009-10-05 07:54
Location: enzed
Has thanked: 12 times
Been thanked: 66 times

Re: Package/Packaging Rant

#13 Post by dilberts_left_nut »

In general (and notwithstanding the bits you have quoted) most documentation is aimed at stable - testing and sid changes a lot and users are expected to be a bit more able to figure things out themselves.

I don't recall reading the specific instructions you are looking for, but logically, if package dependencies change, as is often the case in both sid and testing, 'full-upgrade' is REQUIRED to make the necessary changes for a coherent and up to date system.
Your previous experience of breakage is simply what testing does (it calms down later in the cycle, nearer the freeze) and NOT caused by using 'dist-upgrade'.
Just not updating (or using 'safe-upgrade') really isn't a viable way to run testing.
AdrianTM wrote:There's no hacker in my grandma...

spacex
Posts: 637
Joined: 2015-01-17 01:27

Re: Package/Packaging Rant

#14 Post by spacex »

dilberts_left_nut wrote: Just not updating (or using 'safe-upgrade') really isn't a viable way to run testing.
+1
Yup. I don't care what the documentation for Package Management might say, because it's obviously written for stable, as most of the Debian documentation are. There is no doubt that full upgrade is needed frequently in testing/unstable. You can ease up a little close to the freeze, but don't let it go more than a week between full upgrades. Personally I do it once a day. Makes it a lot easier to manage and control, because then it's only a few packages to verify every time. If you wait for months then it becomes several hundred packages, and then you are much more likely to just accept everything without verifying anything.

stoaphil
Posts: 14
Joined: 2013-08-08 23:53

Re: Package/Packaging Rant

#15 Post by stoaphil »

Over the past couple of days I've had the chance to re-acquaint myself with two of Debian's gems - Aoki's updated Debian Reference[1] and the Debian Administrator's Handbook.[2] I had read both of these a couple of years ago, and apparently more than a few "rules" have changed, at least as to packaging tools.

Specifically, as to mixing aptitude and apt-get, Aoki's tome at section 2.2.2 specifies that action is now apparently OK:
Since apt-get and aptitude share auto-installed package status (see Section 2.5.5, “The package state for APT”) after lenny, you can mix these tools without major troubles (see Bug #594490)."
Also, the exact issue I was faced with above, i.e., the aptitude conflict-spew, is also well-documented by Aoki at section 2.2.1:
The aptitude command sometimes suggests mass package removals for the system upgrade on the testing or unstable Debian system.

-This situation has frightened many system administrators. Don't panic.

-This seems to be caused mostly by the version skew among packages depended or recommended by a meta-package such as gnome-core.

-This can be resolved by selecting "Cancel pending actions" in the aptitude command menu, exiting aptitude, and using "apt-get dist-upgrade".
One topic I found most compelling was the mixing of repositories on the testing/unstable machine (yes, some vitriol from @dasein on this is possible) as explained in the Administrator's Handbook:
6.1.3. Repositories for Testing/Unstable Users
Here is a standard sources.list for a system running the Testing or Unstable version of Debian:
Example 6.2. /etc/apt/sources.list file for users of Debian Testing/Unstable

# Unstable
deb http://ftp.debian.org/debian unstable main contrib non-free
deb-src http://ftp.debian.org/debian unstable main contrib non-free

# Testing
deb http://ftp.debian.org/debian testing main contrib non-free
deb-src http://ftp.debian.org/debian testing main contrib non-free

# Stable
deb http://ftp.debian.org/debian stable main contrib non-free
deb-src http://ftp.debian.org/debian stable main contrib non-free

# Security updates
deb http://security.debian.org/ stable/updates main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free


With this sources.list file APT will install packages from Unstable. If that is not desired, use the APT::Default-Release setting (see Section 6.2.3, “System Upgrade”) to instruct APT to pick packages from another distribution (most likely Testing in this case).
There are good reasons to include all those repositories, even though a single one should be enough. Testing users will appreciate the possibility to cherry-pick a fixed package from Unstable when the version in Testing is affected by an annoying bug. On the opposite, Unstable users bitten by unexpected regressions have the possibility to downgrade packages to their (supposedly working) Testing version.
The inclusion of Stable is more debatable but it often gives access to some packages which have been removed from the development versions. It also ensures that you get the latest updates for packages which have not been modified since the last stable release.
Also very interesting was Aoki's advice regarding the transition around the time of a new release at section 2.1.4:
Caution!

For about few months after a new stable release, most desktop users should use the stable archive with its security updates even if they usually use unstable or testing archives. For this transition period, both unstable and testing archives are not good for most people. Your system is difficult to keep in good working condition with the unstable archive since it suffers surges of major upgrades for core packages. The testing archive is not useful either since it contains mostly the same content as the stable archive without its security support (Debian testing-security-announce 2008-12). After a month or so, the unstable archive may be usable if you are careful.
Of course, all this was explained by dilberts_left_nut, fireExit, and spacex above, and now we have the citations to authority proving their assertions. Thanks!

Based upon the foregoing, I "upgraded" with "apt-get dist-upgrade," cleaned-up the system (including old kernel-cruft) with "autoremove," and all is well, at least as far as Rant #3 goes. As far as Rants #1 and #2 go, a careful mixing of repositories may be the answer.

Thanks again for your explanations.

[1] https://www.debian.org/doc/manuals/debian-reference/
[2] https://www.debian.org/doc/manuals/debian-handbook/

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Package/Packaging Rant

#16 Post by Head_on_a_Stick »

stoaphil wrote:One topic I found most compelling was the mixing of repositories on the testing/unstable machine (yes, some vitriol from @dasein on this is possible) as explained in the Administrator's Handbook:
6.1.3. Repositories for Testing/Unstable Users
The problem is mixing repositories on a Debian stable system, of course mixing in a testing/unstable system may sometimes even be required to get the machine working, that is not in question.

I don't see what the sources.list you have quoted has to do with Debian stable.
:roll:
deadbang

stoaphil
Posts: 14
Joined: 2013-08-08 23:53

Re: Package/Packaging Rant

#17 Post by stoaphil »

head_on_a_stick wrote:
I don't see what the sources.list you have quoted has to do with Debian stable.
Nothing in this tread has anything to do with running stable. I only noted I found it compelling, as I hadn't seen that particular description of it before.

Post Reply