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

Re: Updating the release notes

On 16 Jul 2000, Miguel Wooding SF Ten.Union wrote:

> The release notes that are at
> http://www.debian.org/releases/frozen/i386/release-notes are still
> version 2.2.15, dated 25 May 2000.  Is there a newer version?  There
> are a couple of items in the release notes that have been discussed in
> this list but have not yet been corrected.  (By the way, is there a
> way to submit a bug to the release notes? I didn't see it in the bug
> tracking system.)

I don't think there is a proper entry in the BTS for this kind of thing (i.e.
a document that is not contained in any package). Maybe it would be an idea to
add a virtual "debian-documentation" package with debian-doc@lists as

In the meantime, debian-doc@lists can/should be used for this stuff.

> (1) In upgrading to perl-5.005, any package that has an explicit
> dependency on perl-5.005 (or a dependency on another package depending 
> on perl-5.005, like debconf) gets removed if you dist-upgrade
> directly. A work-around is to upgrade perl first, then remove perl,
> then dist-upgrade.  Like so:
> apt-get update
> apt-get install perl 
> apt-get remove perl
> apt-get dist-upgrade

Hmm. Still not fixed?

But, when using this, don't all perl-using packages get removed, too?

> See below for an earlier discussion of the issue.
> There may be other steps that are recommended before dist-upgrading.
> I don't know whether it made any difference or not, but I started by
> upgrading apt and dpkg. Someone else suggested (on debian-user)
> upgrading ldso and libc6 before doing the dist-upgrade.  As far as I
> know that's not necessary, but it may be.  I also needed to upgrade
> console-tools to prevent it from being removed, but I haven't looked
> into that further to see what caused that and whether it would likely
> be an issue for other folks. Perhaps someone in the know could comment
> on the various problematic upgrade issues before the release notes are
> finalized.

Please do. The more feedback, the better.

> (2) As I understand it, there will be two versions of the cd images,
> one that is allowed to be exported from the US to other countries and
> a second that is not.  CD-ROM distributors are encouraged to produce
> the non-exportable versions, not the exportable versions, as the only
> restriction on these is they cannot be produced inside the US and then
> exported.  Vendors producing CD-ROM's from outside the US can sell
> them anywhere, and most vendors producing them from inside the US are
> selling them here, not overseas.  This seems to me to be an eminently
Ask any big vendor and they'll tell you that they get orders from all over the

> reasonable recommendation.
> If this understanding is correct, then the discussion in the release
> notes is misleading.  It states:
>   The Official CD-ROM distribution ships as three binary package
>   CD-ROMs, containing the "main" and "contrib" sections. If a vendor
>   adds "non-US/main" or portions of "non-free" or "non-US/non-free"
>   sections to a CD set, there may be four binary CDs.
> This should be changed to explain that the recommended official
> version that includes non-US, and that there is also another official
> version that is exportable from the US.
   of the Binary-1 CD

This addition seems reasonable; though I doubt many CD vendors will read it.

>   Again, as I understand it,
> either of these versions is three CD's.  Then it can go on to explain
> why there might be four binary CD's.
> Also, is it correct that the official CD includes contrib?  I thought
> it only included main.

Contrib is part of Debian and thus included on the CDs.

> (3) There were suggestions in debian-devel that we document the fact
> that a newer version of freeciv and (and perhaps other packages?) is
> in woody.  See, for example,
> http://www.debian.org/Lists-Archives/debian-devel-0007/msg00032.html.
> I don't know whether this suggestion was rejected or just forgotten;
> I don't have a strong feeling about it.

Maybe already documented; I haven't seen the latest version.

  Anne Bezemer

> Earlier discussion about perl upgrade issues:
> mwooding@thecity.sfsu.edu (Miguel Wooding SF Ten.Union) writes:
> > Josip Rodin <joy@cibalia.gkvk.hr> writes:
> > 
> > > On Sat, Jun 24, 2000 at 04:20:28AM -0700, Miguel Wooding SF Ten.Union wrote:
> > > > It appears that the problem is that perl-5.005 depends on
> > > > perl-5.005-base, which in turn conflicts with perl.  apt doesn't seem
> > > > to figure out that it can upgrade perl to the new dummy package,
> > > > install perl-5.004 to satisfy the dummy perl's dependency, and then
> > > > remove perl to satisfy the conflict with perl-5.005-base.
> > > 
> > > That problem still exists? Darn... it shouldn't happen.
> > > 
> > > We'll document it better in the Release Notes if it doesn't get fixed.
> > 
> > As I look at it further, it seems like it's a fairly substantial
> > problem.  If I understand correctly, it means that any package that
> > Depends: on perl-5.005 (or, as in the case of scwm, on any other
> > package that Depends on perl-5.005, recursively) can't be upgraded
> > using apt-get.  That's a substantial number of packages.  Just to get
> > a rough idea, I counted some of them:
> > 
> > $ apt-cache dumpavail|egrep "^Depends:.*perl-5.005"|wc -l
> >      79
> > $ apt-cache dumpavail|egrep "^Depends:.*debconf"|wc -l
> >      33
> > 
> > Now, not all of these packages are necessarily in slink, so upgrading
> > might not be an issue, but then again there are others (again, like
> > scwm) that are farther removed and aren't counted here.  A couple
> > other packages that don't upgrade include gnuplot and lynx.
> > Undoubtedly there are more.  (I think that lynx, at least, is silently
> > left at the previous version rather than being removed or upgraded.  I
> > don't know whether others also get removed, as scwm does, as a result
> > of this bug.  Removal is clearly a much more serious problem than
> > simple failure to upgrade, but the latter seems like a concern as
> > well.  When I have time later I'll try to look at that further...)
> > 
> > Debian is (justifiably) much-vaunted for its easy upgrade path; this
> > would significantly tarnish its reputation on this score.  I know
> > potato is about to release, but it would be really nice to have
> > upgrades work properly.  I suppose documenting that they don't work
> > right is better than nothing, but it's still not optimal.  I hope that
> > I'm over-estimating the extent of the problem but I fear that I am
> > not.

Reply to: