Re: why this marketing stuff is important

[Dale Scheetz <dwarf@polaris.net>]

On Sun, 17 Aug 1997, Craig Sanders wrote:

> On Sat, 16 Aug 1997, Dale Scheetz wrote:
> 
> > On Fri, 15 Aug 1997, Craig Sanders wrote:
> > 
> > > i'd like to see them in bookshops too - but not at the price of
> > > completely destroying debian's dynamic update nature (which is, imo, one
> > > of debian's best features)
> > 
> > We can do both. For the retailer it is a matter of not changing the
> > release numbers. The way we deal with prompt fixes and updates has little
> > to do with what order they go into the stable distribution, so why assign
> > any numbers to those changes (outside the version numbering of the
> > packages themselves)? It isn't necessary.
> 
> i agree. i see very little point in a version number for debian itself.
> it's the package versions which are important.

Absolutely. However the release versions are important. They represent a
collection of packages that "work together". They also have specific
library needs when trying to "place" an unstable package into stable.

> > We can support both.
> >
> > When hamm passes through "frozen" and becomes "stable", if it is
> > called 2.0 then a link to hamm from 2.0 gets created, along with
> > hamm-updates and hamm-testing. Packages that their maintainer
> > thinks will fix problems in hamm are directed for installation in
> > hamm-testing. When they have been "adequately" tested, they become
> > candidates for hamm-updates. The directory, hamm-updates, should
> > contain a ChangeLog that contains the changes registered against
> > each of the packages found in hamm-updates, so that users can easily
> > identify which packages they need from updates and which they can
> > leave alone, without having to download the whole pile of packages.
> 
> expecting the users to do all that manually is too much. that sort of
> thing is what computers are for....and dselect can already do it.
> 
> a new tree (stable-updates) populated by packages and symlinks into
> stable for dselect to use does this much better...especially when you
> have several machines to administer/update/keep secure.  One of the
> reasons I use debian is that i don't have to download numerous update
> files to several dozen machines - i just point dselect at my mirror,
> choose the latest stable or unstable tree, and then run Update, Select,
> Install etc.
> 
> I don't care what the directory is called, or whether it has a new minor
> or minor.minor number on it as long as the directory is there for users
> to point dselect at.
> 
> i think that just calling it stable-updates or stable-fixed (with no
> revision number or date) would be an acceptable compromise.  Crippling
> debian's dynamic update nature (by deliberately choosing not to make a
> dselect-able tree) is not acceptable.

I'm not sure that it needs to be this complex. If bo-updates is provided
with an up-to-date Packages file there is no reason that dselect can't use
the directory. (Possibly point the "local" archive at this directory)

> 
> we did something similar to this for rex, but with minor version
> numbers. if the minor versions are causing problems for cd makers then
> get rid of the numbers, not the dselect tree.
> 
> (i've always thought that the only reason we have a version number for
> debian-as-a-whole is for CD-rom makers anyway - in debian, the only
> version numbers that really matter are the versions of the individual
> packages)

While I agree in principle, there IS value in a release version. It is not
always sufficient just to know what version of a package you have, you
also need to know which release it was targeted for.

> > Does this satisfy your needs for timely fixes? I know that for some,
> > unstable is their first recourse to problems with the stable release,
> > while others want those fixes to propogate into stable. 
> 
> i use unstable on my workstations, and stable on my "production" server
> machines...when unstable gets stable enough, the servers get unstable
> too.
> 
> i think that only the most important security and bug fixes should propagate
> from unstable to stable.
> 
> 
> > (Some of these just can't be moved "down" into stable, because of
> > dependencies on unstable packages that will never move into stable
> > {like libc6})
> 
> yes, that's true. at some point in the next few months, it wont be
> feasible to make updated packages for libc5/stable - too many packages
> will have changed, and too much will depend on packages only available
> in unstable.
>
The problem is for the maintainer, who must find a way to build packages
for stable even when his own development system has progressed into
unstable. One way to deal with this might be to provide a "stable"
platform, accessable on the internet, for maintainer to build packages
targeted for stable?
 
Luck,

Dwarf
-- 
_-_-_-_-_-_-                                          _-_-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .