[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: No 'self life' of packages.



On 10/9/2011 3:57 AM, dE . wrote:
Hi.

I'm using Debian testing for use with Win/Mac migrants, it's good but has a lot of problems also, one of which I'd like to address.

Suppose I serviced a Desktop PC for some friend and he didn't update it for a week, in the mean time in the testing tree, packages update and the old packages are removed. If the end user wants to install a package which pulls this removed package, download fails and the user is bewildered.

Updating is not a good idea since it usually results in major dependency issues with core libraries, thus effectively, one has to upgrade the system which results in more than 700MB downloads (in a month old system) which takes a long time, also issues may arise after the upgrade.

That's what I meant by shelf life; I'd suggest the package should stay for a longer period before being removed. This will require a lot of space though, but that's cheep nowadays. As an alternative, I suggest a separate set of mirrors specifically for this purpose.

Debian stable is too old (contains FF 3.5 and chromium 6) which miss out a few enhancements which might be necessary for the user; backports ain't always available and there're no updates for them. These are suggestions to make the testing branch appear less dynamic and more suitable for the Desktop.

I'm discussing this on both debian-desktop and debian-testing.

Well if you are using this in a production environment, it's kinda crazy to use the testing version.  Also, if you aren't happy with what's available prepackaged, you could always download the source code to what you want and build your own package.  As far as updating, if you are using the testing build, then updating often is, IMO, a good idea.  If anything to keep up with all the latest bug fixes and feature enhancements/additions. 

Debian stable too old?  That's a matter of opinion.  I'd rather run stable on a production box than testing (although I do have two production boxes running each -- stable for day to day stuff that people use for reliability and a production testing box for those that like to use bleeding edge -- both of which have mirrored/replicated data using GlusterFS).

Reply to: