Linux Archive - When stability is pointless

Linux Archive (http://www.linux-archive.org/)

- Debian User (http://www.linux-archive.org/debian-user/)

- - When stability is pointless (http://www.linux-archive.org/debian-user/187972-when-stability-pointless.html)

When stability is pointless

With apologies for cross-posting.

Dear all,

I have copied below the text of a blog post* I wrote a few minutes
ago, because it addresses an issue in Debian and Debian-derived
distros that I've encountered several times, and which no doubt many
people encounter frequently. It's an issue which seems, to judge by
forum posts and mailing list requests, to generate a fair amount of
traffic and expenditure of effort, but which has not really been
tackled in a co-ordinated way as far as I am aware.

Consequently, I've written this piece (which is intended for a general
audience) in order to raise awareness of the issue, and to seek a
co-ordinated effort to tackle it.

Yours respectfully,

Sam Kuper

*URL: http://www.sampablokuper.com/blog/2008/11/05/when-stability-is-pointless/

When stability is pointless
===========================

Many Linux distributions (and other software environments too) use
package managers to facilitate the installation, upgrading and
uninstallation of software packages as needed. At least, that's the
idea.

Why have package managers?
--------------------------

Are package managers necessary? Well, no. One way of managing software
is simply to install individual software programs/libraries as needed,
and allow each item to handle its own updating or uninstallation (or
even just leave that to the user to do manually). That's pretty much
how Windows handles things. It works OK if it isn't crucial that your
programs aren't able to communicate with each other beyond basic,
operating system level mechanisms like cut-and-paste. If your programs
depend on each other, however, you'd be in trouble if you removed a
piece of software that another piece depended on, or installed a piece
without installing its dependencies, etc.

Linux distributions usually have many pieces of software that are
inter-dependent. A package manager can keep track of those
dependencies and can, for instance, inform a user about to uninstall a
piece of software of which other packages will be affected by this.
That's important, because otherwise the user might accidentally
disable something crucial.
Package managers can also make upgrading software, to take onboard the
latest security patches, trivial, requiring only one or two commands
in order to automatically upgrade all the packages on an entire system
for which upgrades are available.

I haven't investigated the historical origins of package management,
so I can't claim to know the original reason why package managers came
to exist. But I can state from experience that package managers, when
they work well, make life easier than it would otherwise be for system
administrators running Linux systems with interdependent packages.

Stability
---------

Package managers facilitate stability. Given the foregoing, this
should come as no surprise. Yet in the context of many Linux
distributions, stability means something more specific than the
colloquial "reliable, consistent" sort of meaning that the term
normally implies. Stability, in the context of these distributions,
means "unchanging, except with regard to security". One such
distribution is Debian.

Through the magic of package managers, Debian maintainers maintain
multiple packages of each original software item they want to make
available to users. The reason for the multiple packages is normally
to achieve stability. The stability is achieved by packaging a version
of the original software that has been tested sufficiently to warrant
confidence in its security: it is not known to compromise systems on
which it runs (except in cases where it may do so by explicit design).
This "stable" package is then offered to users for, typcially, many
years, and is not altered in any way except if a security flaw is
discovered in it. Only if a security is found will the package be
modified: to patch the flaw.

Meanwhile, the maintainer will keep an eye on new versions of the
original software. When the maintainer thinks a new version is worth
packaging, she may package it as an "unstable" package to begin with,
and then subsequently a "testing" package. If, as the release of a new
version of Debian is approaching, the "testing" package meets
sufficient criteria indicating its suitability for being regarded as
"stable", then it, too, is marked as "stable" for that new release of
Debian, and is thereafter treated as described above.

As such, Debian may have multiple packages for the same piece of
software: "stable" packages for current and old versions of Debian,
and "unstable" and/or "testing" packages. Usually, each of these
packages will be based upon a different version of the original
software. In a hypothetical case, the "stable" package for the current
Debian stable release might contain version 3.1 of the original
software (perhaps with security patches, as described above); the
previous Debian stable release might have packaged version 1.0 of the
original software. The current "testing" version of Debian might
package version 3.9 of the original software, and the "unstable"
version of Debian might package version 4.2 of the original software.

But…
----

Sometimes, stability lets you down.

My perception is that the greatest problems with the system of
"stability" practised by Debian and other Linux communities arise when
the upstream developer has not maintained the documentation for
earlier versions of the software he has written. This leads to a
disconnect between users reliant on package managemers and interested
in dependability, and developers interested in making software that is
faster, more fully featured, or otherwise different from the earlier
versions of their software.

An example
----------

Here is my scenario. I have a server running Ubuntu 8.04 LTS: a
"stable", recent release of a Debian-based Linux distribution. I wish
to install a security-related program called "psad" (short for "Port
Scan Attack Detector) on that server. However, the stable package of
psad for Ubuntu 8.04 turns out to house version 2.1 of psad. That
wouldn't bother me, except that… I can't set it up!

The reason I'm having difficulty setting it up is that the
documentation on installing psad refer not to version 2.1 but to
version 2.1.4, which requires setting up differently to 2.1. The
developer's recommendation is that I upgrade to a more recent version,
but two questions arise:

* how?

* why?

The how question has several possible answers. I could forego package
management altogether for psad and install version 2.1.4 straight from
the source code. But that would entail the problems outlined above:
the problems package management solves. Alternatively, I could perhaps
configure my server to attempt to use an "ubstable" or "testing"
Ubuntu psad package in place of the stable one for 8.04.

But why? Why should I have to do this, if the "stable" package is good
enough that it was chosen for "stable" release?
This is where the disconnect I alluded to above becomes apparent.
Developers may not always explicitly deprecate their old code, but
they nearly always do deprecate it anyway. The response of Michael
Rash, the psad developer, was characteristic of this.

Yet as far as users of stable distributions are concerned, that same
sofware - the oldish versions of the program - has not been
deprecated: it's still in the latest "stable" repositories.

There's a contradiction here.

Unfortunately, it's an unresolved contradiction, as far as I can tell.
I encountered it previously with rkhunter, also a piece of security
software I wanted to install onto a software running a "stable"
version of Linux. In that case, it was even worse: the upstream
developer had explicitly deprecated the version that was in the
current (read: un-deprecated) "stable" package, and was entirely
unwilling to support it.

Clarification
-------------

Despite these problems, I'm still very grateful to - and have a lot of
respect for - the developers and maintainers of the software I use
(including the software I've mentioned above). Michael Rash's software
is innovative and free (in both senses of the word), and he was
certainly under no formal obligation to reply to my queries.
Furthermore, I have learned a good deal from reading his book.
Equally, rkhunter *can* be a useful tool even if you aren't using the
very latest version of it, and the maintainers who answered my queries
also did so voluntarily and courteously.
Yet the problem remains: when developers deprecate software that
maintainers have not deprecated, users are left in the lurch with
software they can't use, can't get much support for, or can't find
documetation for.

Solution
--------

In some ways, I'm still very much a newcomer to the free software
world. It's only in the last 2-3 years that I've really begun feeding
back to the communities whose tools I use, and I have not become a
developer or maintainer myself. As such, I'm not yet in a position to
implement change to, say, Debian's release policy.
Yet, I do have some ideas for solving the problem I've outlined in this piece:

* Raise awareness of the problem.

* Propose that maintainers open a dialogue with the developers whose
software they package to request that developers continue to support,
or at least maintain documentation for, old versions of their software
until the maintainers have deprecated it.

* Ask the maintainers to shoulder this burden where the developers
cannot or will not do so.

* Seek further suggestions from the community.

In the first instance, I'm going to attempt to make some progress
towards realising these solutions by posting a link to this piece to
the Debian and Ubuntu mailing lists. Then I'll leave it in the
community's hands unless I find I have any more to add.

When stability is pointless

On Wed, Nov 05, 2008 at 01:26:31AM +0000, Sam Kuper wrote:
[snip long preamble]

> Sometimes, stability lets you down.
>
> My perception is that the greatest problems with the system of
> "stability" practised by Debian and other Linux communities arise when
> the upstream developer has not maintained the documentation for
> earlier versions of the software he has written. This leads to a
> disconnect between users reliant on package managemers and interested
> in dependability, and developers interested in making software that is
> faster, more fully featured, or otherwise different from the earlier
> versions of their software.
>
> An example
> ----------
>
> Here is my scenario. I have a server running Ubuntu 8.04 LTS: a
> "stable", recent release of a Debian-based Linux distribution. I wish
> to install a security-related program called "psad" (short for "Port
> Scan Attack Detector) on that server. However, the stable package of
> psad for Ubuntu 8.04 turns out to house version 2.1 of psad. That
> wouldn't bother me, except that??? I can't set it up!
> The reason I'm having difficulty setting it up is that the
> documentation on installing psad refer not to version 2.1 but to
> version 2.1.4, which requires setting up differently to 2.1. The
> developer's recommendation is that I upgrade to a more recent version,
> but two questions arise:

If Ubuntu is supplying documentation on how to set up psad for a version
different than the psad binary they supply, then that is a Ubuntu bug.
Or, are you saying that you are trying to implement a psad recipe from
the internet that doesn't apply to the version of psad supplied in
Ubuntu?

For all Ubuntu is based on Debian, I don't think it follows debian
policy. The policy manual says, basically and among other things, that
installing a package should result in that package working
out-of-the-box in some fashion only needing tweaking by the sysadmin.
I've never used psad but I would be very surprised if the problem you
experienced were to happen were you running Debian Stable.

Since Ubuntu is based not on Debian Stable but on (I think) Unstable, I
don't know how one can consider any Ubuntu release to be stable.

Doug.

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

When stability is pointless

Hi Doug,

Thanks for your comments.

2008/11/5 Douglas A. Tutty <dtutty@vianet.ca>:
> Or, are you saying that you are trying to implement a psad recipe from
> the internet that doesn't apply to the version of psad supplied in
> Ubuntu?

Essentially correct. But not just any old set of psad instructions:
the instructions provided on the psad website and in the developer's
book on Linux firewalls. In other words, pretty much the most
comprehensive set of instructions I could find.

> For all Ubuntu is based on Debian, I don't think it follows debian
> policy. The policy manual says, basically and among other things, that
> installing a package should result in that package working
> out-of-the-box in some fashion only needing tweaking by the sysadmin.

Define "working" (or "tweaking"). My experience with some packages in
Etch suggest that Debian sometimes has problems like this too.

> I've never used psad but I would be very surprised if the problem you
> experienced were to happen were you running Debian Stable.

You may be right. Perhaps I should go back to Debian Stable. But one
of the reasons I switched to Ubuntu was to minimise the gap between a
package being deprecated by its developer and deprecated by its
maintainer, in an effort to avoid precisely the sort of problem I
outlined in my post.

> Since Ubuntu is based not on Debian Stable but on (I think) Unstable, I
> don't know how one can consider any Ubuntu release to be stable.

Ubuntu has LTS (Long-Term Support) releases, which roughly translate to Stable.

However, I think this is perhaps missing the point.

Sam

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

When stability is pointless

Sam Kuper wrote:

> Stability
> ---------
>
> Package managers facilitate stability. Given the foregoing, this
> should come as no surprise. Yet in the context of many Linux
> distributions, stability means something more specific than the
> colloquial "reliable, consistent" sort of meaning that the term
> normally implies. Stability, in the context of these distributions,
> means "unchanging, except with regard to security". One such
> distribution is Debian.

Stability is NEVER pointless. However, it /can/ be used as an excuse to
leave a newer package as 'testing' due to the fact that 'if it isn't
broke, don't fix it'. If a newer version of a package provides trivial
changes, /or/ changes that have the potential for security breaches,
then that's a good reason to have the 'latest and greatest'.

Stability in the Debian world (IMHO) tends to mean exactly what you
describe. At least the previous versions from the one due to be
released. It was (and is) impossible to maintain and older Debian OS
because of the lack of any method where honest to goodness 'stable'
packages get moved from the 'testing' repo to the stable one. It became
customary to simply enable the testing repos and be done with it. But
that's not the case with fedora (for example) because it truly is as
bleeding edge as you can get without spending all day/every day finding
and downloading/compiling the latest of everything. In most cases (but
not all admittedly) the fedora packages are 'stable' and work well out
of the box.

>
> Through the magic of package managers, Debian maintainers maintain
> multiple packages of each original software item they want to make
> available to users. The reason for the multiple packages is normally
> to achieve stability. The stability is achieved by packaging a version
> of the original software that has been tested sufficiently to warrant
> confidence in its security: it is not known to compromise systems on
> which it runs (except in cases where it may do so by explicit design).
> This "stable" package is then offered to users for, typcially, many
> years, and is not altered in any way except if a security flaw is
> discovered in it. Only if a security is found will the package be
> modified: to patch the flaw.

Yes, this is true (or was) in the Debian world, but remember, there are
other distros and package managers.

>
> Meanwhile, the maintainer will keep an eye on new versions of the
> original software. When the maintainer thinks a new version is worth
> packaging, she may package it as an "unstable" package to begin with,
> and then subsequently a "testing" package. If, as the release of a new
> version of Debian is approaching, the "testing" package meets
> sufficient criteria indicating its suitability for being regarded as
> "stable", then it, too, is marked as "stable" for that new release of
> Debian, and is thereafter treated as described above.

Well, yeah, maintainers aren't always on company payroll to maintain
software. We rather are at their mercy when it comes to this.

>
> As such, Debian may have multiple packages for the same piece of
> software: "stable" packages for current and old versions of Debian,
> and "unstable" and/or "testing" packages. Usually, each of these
> packages will be based upon a different version of the original
> software. In a hypothetical case, the "stable" package for the current
> Debian stable release might contain version 3.1 of the original
> software (perhaps with security patches, as described above); the
> previous Debian stable release might have packaged version 1.0 of the
> original software. The current "testing" version of Debian might
> package version 3.9 of the original software, and the "unstable"
> version of Debian might package version 4.2 of the original software.

I'm not EVEN going to break out my soapbox on how freaking bad Debian's
repos are, nor their horrible maintenance of said repos. It's a
complete joke. This is the IDEAL case of a decent OS getting KILLED by
it's horrible QA/Maintenance team.

>
> But…
> ----
>
> Sometimes, stability lets you down.

No, this isn't really accurate based on what you say below. This isn't a
stability problem, but a problem with the individual maintainers.

>
> My perception is that the greatest problems with the system of
> "stability" practised by Debian and other Linux communities arise when
> the upstream developer has not maintained the documentation for
> earlier versions of the software he has written. This leads to a
> disconnect between users reliant on package managemers and interested
> in dependability, and developers interested in making software that is
> faster, more fully featured, or otherwise different from the earlier
> versions of their software.

Look, it's true the OD (original developer) may not keep older versions
up to date documentation wise. That does happen, but that's NOT the
package maintainers fault. It /is/ their fault, however, if they
include docs for a newer version of the software with an older version
of the code.

>
> An example
> ----------
>
> Here is my scenario. I have a server running Ubuntu 8.04 LTS: a
> "stable", recent release of a Debian-based Linux distribution. I wish
> to install a security-related program called "psad" (short for "Port
> Scan Attack Detector) on that server. However, the stable package of
> psad for Ubuntu 8.04 turns out to house version 2.1 of psad. That
> wouldn't bother me, except that… I can't set it up!
>
> The reason I'm having difficulty setting it up is that the
> documentation on installing psad refer not to version 2.1 but to
> version 2.1.4, which requires setting up differently to 2.1. The
> developer's recommendation is that I upgrade to a more recent version,
> but two questions arise:

Okay, are we talking documentation carried over with the package
install? Or on the apps' website? If it's included with with package,
then that's a problem with the maintainer simply NOT paying attention.
If it's on the website, it's a bitch, but it does happen. Most devs
will leave older version docs posted but not all. But then, that's what
the community is for. :)

>
> * how?
>
> * why?
>
> The how question has several possible answers. I could forego package
> management altogether for psad and install version 2.1.4 straight from
> the source code. But that would entail the problems outlined above:
> the problems package management solves. Alternatively, I could perhaps
> configure my server to attempt to use an "ubstable" or "testing"
> Ubuntu psad package in place of the stable one for 8.04.

There IS a third option not mentioned here. You could build your OWN
PACKAGE with the newer version of the software. I've had to do this
ALOT over the years for the very reason you describe, a package I want
has a newer version that a binary package isn't available yet (or ever),
or it's a newer app, but I need it on an older (unsupported) OS.
(Typically an older fedora version getting newer software RPMs. This
gets you the latest version for the OS you want, and you can always post
the newer package or submit to the current maintainer for him to debug/use.

I've done that as well. I don't mind posting the work I've done for
someone else to use if I think it will be handy for a few folks.

>
> But why? Why should I have to do this, if the "stable" package is good
> enough that it was chosen for "stable" release?
> This is where the disconnect I alluded to above becomes apparent.
> Developers may not always explicitly deprecate their old code, but
> they nearly always do deprecate it anyway. The response of Michael
> Rash, the psad developer, was characteristic of this.

Yes, but truly that's the 'stock' answer from ANY developer, to upgrade
to the newest version. Unless you are Microsoft, (r others) who get
paid to maintain older versions of software, you won't want to do it
that much.
>
> Yet as far as users of stable distributions are concerned, that same
> sofware - the oldish versions of the program - has not been
> deprecated: it's still in the latest "stable" repositories.
>
> There's a contradiction here.

This isn't a contradiction. Not in a true sense of the word. It's more
'unfortunate' rather than a contradiction. Any stable package is left
in stable /until/ it's superseded by a newer version in any distro.
That's because, if you pull it because it's not the newest, how would
someone who needs /any/ version of that software to install it from a repo?

It's more aggravating than a contradiction.

>
> Unfortunately, it's an unresolved contradiction, as far as I can tell.
> I encountered it previously with rkhunter, also a piece of security
> software I wanted to install onto a software running a "stable"
> version of Linux. In that case, it was even worse: the upstream
> developer had explicitly deprecated the version that was in the
> current (read: un-deprecated) "stable" package, and was entirely
> unwilling to support it.

Yeah, that's a bit of a pain, but that is also life in FOSS. There
aren't enough knowledgeable people with the time needed to put into
maintaining all the packages (or potential packages) out there.

>
> Clarification
> -------------
>
> Despite these problems, I'm still very grateful to - and have a lot of
> respect for - the developers and maintainers of the software I use
> (including the software I've mentioned above). Michael Rash's software
> is innovative and free (in both senses of the word), and he was
> certainly under no formal obligation to reply to my queries.
> Furthermore, I have learned a good deal from reading his book.
> Equally, rkhunter *can* be a useful tool even if you aren't using the
> very latest version of it, and the maintainers who answered my queries
> also did so voluntarily and courteously.
> Yet the problem remains: when developers deprecate software that
> maintainers have not deprecated, users are left in the lurch with
> software they can't use, can't get much support for, or can't find
> documetation for.

Not always true, but I can sense your frustration. It's a pickle to be in.

>
> Solution
> --------
>
> In some ways, I'm still very much a newcomer to the free software
> world. It's only in the last 2-3 years that I've really begun feeding
> back to the communities whose tools I use, and I have not become a
> developer or maintainer myself. As such, I'm not yet in a position to
> implement change to, say, Debian's release policy.
> Yet, I do have some ideas for solving the problem I've outlined in this piece:
>
> * Raise awareness of the problem.

I'm almost sure they know the problem, and do what they can to eliminate
it, but see my post above about manpower, it's just not there all the time.

>
> * Propose that maintainers open a dialogue with the developers whose
> software they package to request that developers continue to support,
> or at least maintain documentation for, old versions of their software
> until the maintainers have deprecated it.

Again, see above.

>
> * Ask the maintainers to shoulder this burden where the developers
> cannot or will not do so.

Look, maintainers do all they can to make that not a problem, but there
isn't always a compelling need to update widget-1.0 to widget-1.1 until
after everything else is done, or EVER if that app isn't used much or
isn't maintained upstream.

>
> * Seek further suggestions from the community.
>
> In the first instance, I'm going to attempt to make some progress
> towards realising these solutions by posting a link to this piece to
> the Debian and Ubuntu mailing lists. Then I'll leave it in the
> community's hands unless I find I have any more to add.

We've all been where you are. I was there just a few weeks ago. I had
to build the patched BIND version for the Kaminsky exploit for Debian
sarge for that VERY reason. I also had to patch Fedora Core 6's BIND
with a patched RPM I built myself. It's not always fun, or easy to
build them yourself, but it can be done when needed.

--
Frustra laborant quotquot se calculationibus fatigant pro inventione
quadraturae circuli

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

When stability is pointless

Adding my two cents here.

Ubuntu needs a system for restoring old settings when new packages are
installed so its possible to roll the OS back to the old settings.
Sort of like Restore Points in Windows, and Linux needs a more
reliable means of uninstalling installed packages. Synaptic and Adept
do this now but to a limited degree. If a new package you install
requires a lot of dependent packages which are downloaded also and you
uninstall the one that called for those dependencies the packages
added as dependencies don't get uninstalled along with it. You have
to guess at which ones you don't need and manually remove them one by
one. The Package Manager should keep track of these dependencies and
remove dependent packages when you uninstall something unless its
required by something else that's still installed. This and the
Restore Point recovery system would go a long way towards helping to
improve the stability of Linux whether it be Debian, Red Hat, or
Slackware based.

The same should apply to applications which must be installed via
alternative methods like the "make install" compile method.

--
Michael "TheZorch" Haney
thezorch@gmail.com
http://thezorch.googlepages.com/home
AIM: thezorch@gmail.com
Yahoo IM: zorchhaney
ICQ: 343230252
GoogleTalk: thezorch
MSN Messeger: haneymichael@hotmail.com
Free You Computer from the Tyranny of Microsoft www.ubuntu.com

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

When stability is pointless

On Wed, Nov 5, 2008 at 8:52 AM, Michael Haney <thezorch@gmail.com> wrote:

Adding my two cents here.

Ubuntu needs a system for restoring old settings when new packages are

installed so its possible to roll the OS back to the old settings.

Sort of like Restore Points in Windows, and Linux needs a more

reliable means of uninstalling installed packages. *Synaptic and Adept

do this now but to a limited degree. *If a new package you install

requires a lot of dependent packages which are downloaded also and you

uninstall the one that called for those dependencies the packages

added as dependencies don't get uninstalled along with it. *You have

to guess at which ones you don't need and manually remove them one by

one. *The Package Manager should keep track of these dependencies and

remove dependent packages when you uninstall something unless its

required by something else that's still installed.<snip>

If I understand whats being said above, you are talking about apt-get autoremove?

--
Regards,
Amit Joshi

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

When stability is pointless

Hello,

Sam Kuper wrote:

Hi Doug,

Thanks for your comments.

2008/11/5 Douglas A. Tutty <dtutty@vianet.ca>:

Or, are you saying that you are trying to implement a psad recipe from
the internet that doesn't apply to the version of psad supplied in
Ubuntu?

Essentially correct. But not just any old set of psad instructions:
the instructions provided on the psad website and in the developer's
book on Linux firewalls. In other words, pretty much the most
comprehensive set of instructions I could find.

For all Ubuntu is based on Debian, I don't think it follows debian
policy. The policy manual says, basically and among other things, that
installing a package should result in that package working
out-of-the-box in some fashion only needing tweaking by the sysadmin.

Define "working" (or "tweaking"). My experience with some packages in
Etch suggest that Debian sometimes has problems like this too.

So far I can understand, Etch is not yet stable.

I've never used psad but I would be very surprised if the problem you
experienced were to happen were you running Debian Stable.

You may be right. Perhaps I should go back to Debian Stable. But one
of the reasons I switched to Ubuntu was to minimise the gap between a
package being deprecated by its developer and deprecated by its
maintainer, in an effort to avoid precisely the sort of problem I
outlined in my post.

Since Ubuntu is based not on Debian Stable but on (I think) Unstable, I
don't know how one can consider any Ubuntu release to be stable.

Ubuntu has LTS (Long-Term Support) releases, which roughly translate to Stable.

However, I think this is perhaps missing the point.

Sam

hth,
Jerome

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

When stability is pointless

On Tue, 2008-11-04 at 22:22 -0500, Michael Haney wrote:
<snip>
> The same should apply to applications which must be installed via
> alternative methods like the "make install" compile method.
I'm not sure how realistic this is without something to say "hey, keep
track of me". You can't just track everything installed anywhere
whenever the user types "make install" either, because some users may
not want that in all cases. If you really want to keep track of this,
something along the lines of checkinstall[1] might do for tracking
what's installed with "make install", but including dependencies is not
likely trivial. For example, I recently compiled Assult Cube for
64-bit, and it required me to install the development packages (which
themselves install the libraries) for SDL, SDL-image, and SDL-mixer. I
may only require SDL-mixer for Assult Cube but perhaps I require
SDL-image for 3 other things and SDL for an additional 2 other things.
You would need to tell whatever you're using to track your "make
install" changes what other libraries this depends on. That would be
very error-prone, especially if I forget that I installed a package and
remove everything else that depends on it. Suddenly I have something
broken and I may or may not know how to check why.

I'm not saying I disagree with the idea of tracking what's installed
through "make install", I'm just saying that I don't think it's as easy
as I think you're making it sound. Also that the user should be able to
choose for each "make install" whether to track it or not.

[1] http://freshmeat.net/projects/checkinstall/

> --
> Michael "TheZorch" Haney
> thezorch@gmail.com
> http://thezorch.googlepages.com/home
> AIM: thezorch@gmail.com
> Yahoo IM: zorchhaney
> ICQ: 343230252
> GoogleTalk: thezorch
> MSN Messeger: haneymichael@hotmail.com
> Free You Computer from the Tyranny of Microsoft www.ubuntu.com
>
--
Joel Goguen
Bug-free code is a myth.
--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

When stability is pointless

On Wed, Nov 05, 2008 at 11:48:05AM +0800, Jerome BENOIT wrote:

> >Define "working" (or "tweaking"). My experience with some packages in
> >Etch suggest that Debian sometimes has problems like this too.
>
> So far I can understand, Etch is not yet stable.

Etch is so stable, it will soon be old-stable. I think you're thinking
Lenny.

:)

Doug.

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org