Re: dselect oddities
On Sun, 17 May 1998 00:32:29 -0400, Bill Leach wrote:
>Although I admit to now being in the "If it ain't broke, don't fix it!"
>mode myself (while hamm is in frozen), I do not personally subscribe to
>that philosophy. The 'pain' of delaying upgrading to repair bugs can be
>considerable and particularly in the case for Debian, a package upgrade
>rarely breaks itself or anything else. Even during 'hamm' development,
>my own experience was that it was very rare that an upgrade run would
>break anything (until hamm went into 'frozen').
As I have stated there are times when this is catagorically untrue. In
my particular case, to provide as an example, I have placed the "unstable"
directories into dselect's path so I could keep up with new versions of
*applications* while leaving the *libraries* alone.
Hamm does not have the latest SLRN, for example. It has 0.9.4.3 which is
a few months old. There are features in the later 0.9.5.x series I want.
Since hamm is frozen no new versions of SLRN will be placed into its tree.
That means, if I want to upgrade that application when someone packages it up
I must put the "unstable" directories into the path.
When I did that, and dselect upgraded everything, including the
libraries, it broke several other applications. Most notably, sc.
Fortunately, I do have my secondary Linux box running Slackware 3.2 and it
has a functional sc on it so I can continue to plan my finances.
While I agree that leaving security holes open is a bad thing I am of the
opinion that one should not be limited to security only upgrades when it
comes to applications. Upgrading anything blindingly is also a bad thing.
Another example that comes to mind is ncftp. You are aware that ncftp 2.4.x
broke scripting, right? Ncftp 2.3.0 does not have the broken scripting. The
bug has been reported, by me, and has not been fixed.
So what is a person to do when they want to update applications which are
mislabeled as "unstable" and leave the underlying libraries at the "stable"
level? This is not an uncommon want or desire. Just as people want easy
updates I feel people also want reasonable control and the ability to get
applications up to speed.
>To me, it does not make much sense for dselect to require (possibly)
>hundreds of operations to preform an upgrade of the system to current
>levels.
This is an incorrect assessment. As has been pointed out to me one can
set sections to be held. It only follows that the reverse is possible, that
whole sections can be marked for upgrading.
>Even if an option were designed in to allow a selection of the
>default behaviour (automagic upgrade or NO-automagic upgrade) AND a
>single key operation to reverse the default, I still would expect that
>the 'shipping' default would be to upgrade.
Of course. Or have dselect ask the first time it is run with a screen
which explains the bonuses and pitfalls of both approaches.
Let me explain why this got me upset and why I feel that this is odd to
just upgrade at a whim. I ran Slackware for over two years before jumping
onto Debian. I wanted an easier upgrade path than what Slackware offered.
I've had two years of compiling and installing tarballs. I have no problems
doing that, I just don't like it.
However, when I did my own compiling and updating I did exactly what I
said I tried to do above. I left the libaries and underlying OS, in a sense,
alone until it was needed to upgrade for either security reasons or some
application needed it. "If it ain't broke, don't fix it." By the same token
I upgraded most of my applications to the latest version as soon as possible
because, in most cases, the new versions had features or bug fixes I wanted.
I don't know what versions are in bo but hamm hasn't even been called
"stable" yet and most of its applications are outdated. JED is up to .98.4,
SLRN is in the 0.9.5 series which uses the SLANG 1.x series (which was not
present in slink when I last checked, bad dependancy there). Another is mtr.
Hamm has it at 0.14, the latest is 0.22 IIRC.
What has happened is that when I switched from Slackware to Debian, to
the latest reasonably "stable" Debian most of my applications took 2-3 steps
backwards. If I sit down, get my username and PGP in as a developer and
started packaging new applications that still would not change it because
everything I would submit would go into the "unstable" area.
So what we have is a little tug-of-war between two or three schools of
thought and dselect only accomodates one of them, the most conservative, with
default behavior.
--
Steve C. Lamb | Opinions expressed by me are not my
http://www.calweb.com/~morpheus | employer's. They hired me for my
ICQ: 5107343 | skills and labor, not my opinions!
---------------------------------------+-------------------------------------
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: