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
maintainer.
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
world.
> 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.
Regards,
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: