On Sun, May 17, 1998 at 05:07:12PM +1000, Hamish Moffatt wrote:
> Steve, I think you misunderstand what "stable", "unstable" etc are.
No, I am not. I am well aware of it means.
> If you want continued upgrading of your applications, then you should
> track unstable -- currently slink. If you don't, then track stable,
Exactly. But in doing so, with the current defaults in dselect, when I
move to the "unstable" directory it is an all or nothing proposition, I
don't get to pick and choose.
> > 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.
> This is, of course, not always practical. Some newer applications
> will require new libraries.
That is what the dependancies are for. The way that I configured my
current system was to pick the applications that I wanted and let the
dependancies take care of the libraries that are needed.
> > 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.
> Yes, if you want to do it with dselect. No, if you do it with dpkg,
> which is far easier.
According to whose standards? To me dselect is far easier because I
don't have to wade through ~50 command line switches.
> > 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.
> It's an upstream bug, by the sounds of things -- what do you expect
> the maintainer to do? The beauty of open-source software (as NcFTP now
> is) is that if nobody else will fix something, you can always do it yourself.
I don't expect the maintainer to do anything. I used it as an example
of how blind updating can lead to problems. Please keep up with the context
of the conversation.
Also, I really dislike it when people say, "you can always do it
yourself." This, to me, is the pinnicle of arrogance. It makes the
assumption that the person on the other end can program. As stated, I
cannot. My only option was to dig up a copy of ncftp 2.3.0 and compile it.
I have reported the bug, more than once, to the author with no sign of it
being fixed. That is the best I can do. But to offer "fixing it yourself"
as a viable option to one and all is just arrogant.
Awww, your house got blown away in a twister. Nevermind, you can
rebuild it yourself! That is about what it sounds like to me.
> > 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.
> Actually I think generally libraries are more likely to be stable even
> in the unstable tree than applications -- people will scream a lot louder
> if there are broken libraries.
As I mentioned, sc is now broken because of the libraries in slink.
That would not have happened if it weren't for the mindless autoupdate.
> > 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.
> At some point in time, we have to draw the line and say this is what
> will be released. Then it needs testing -- integration testing, which is
> where the stable or unstable label comes from. If we continued to
> put things in to hamm it would never be released. It is already a long
> time since bo's release.
I understand that. I have never contested that. But tell me how the
autoupdating mindset fits into where people want to keep up with the latest?
Would *YOU* autoupdate on the unstable tree for every update out there or
would you pick and choose depending on what your needs are and let the rest
of the packages sit at what you *KNOW* are stable levels?
> But what you get is a system that is tested to be stable. If you keep
> upgrading your system from tarballs, then you have no guarantee that it
> is stable. You can follow slink in Debian, get the latest software,
> and still not get the guarantee. So following unstable is no worse
> than DIY with Slackware.
Except that it automatically installs unless I tell it otherwise. DIY
on Slackware is the reverse, only what I want installed is installed. It is
the subtle difference in the default that makes a huge difference in the
end. My Slackware was based on 3.2. I had updated most of the programs on
it by hand at one time or another. My /usr/local/ directory was slowly
overtaing my /usr tree in size. It was rock solid for two years.
My first experience with Debian and sc breaks because of an autoupdate.
> Having said all that, I have absolutely no idea what it is you want done.
> You want stable software, yet you want the absolute latest versions
> of some software, but not others. I think these goals are incompatible.
No, incorrect. I want a default of *NOT* auto updating. What would be
better is that dselect knew the difference between the "stable" tree and the
"unstable" tree. It allowed autoupdating in one and pick and choose in the
other. The goals are certainly not incompatible as anyone who has done a
DIY Slackware system for longer than a few months can attest to. It is just
PITA as dselect stands right now.
Tell me, what is so hard to understand with this simple concept: No
autoupdating.
--
Steve C. Lamb | Opinions expressed by me are not my
http://www.calweb.com/~morpheus | employer's. They hired me for my
CC: from news not wanted or appreciated| skills and labor, not my opinions!
---------------------------------------+-------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
