aboutsummaryrefslogtreecommitdiffstats
path: root/english/News/weekly/2000/40/index.wml
blob: 6062538628df113288512e0f593cf7fd0dd3e3d0 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
#use wml::debian::weeklynews::header PUBDATE="2000-12-12" SUMMARY="2.2r2 released; package pools arrive in full; apt ported to rpm"

<p>
<b>Welcome</b> to Debian Weekly News, a newsletter for the Debian community.
</p>

<p>
<b>Debian 2.2r2</b> was <a href="../../../../News/2000/20001205">released</a> last
week. Of course it consists mostly of security fixes and important bug fixes.
The problems with r1 should all be fixed in this release. CD images are
still propagating to the mirrors.
</p>

<p>
<a name="main"></a>
<b>The main Debian archive was just moved into a package pool.</b> There's
little to see yet, but packages will move into a "pool" directory when new
versions are uploaded. There has been some confusion about package pools,
and so here is a <a href="http://people.debian.org/~joeyh/poolfaq">short FAQ</a>
on the subject. In the <a href="mail#mail1">announcement</a>, James Troup cautions: "<i>Despite the relative 
catastrophe-free implementation on non-US, I suspect many more
problems will crop up in the main archive.</i>".
</p>

<p>
<b>Apt has been ported to rpm</b> by Conectiva, who modified it so it can
handle rpm packages. A 
<a href="http://freshmeat.net/news/2000/12/02/975819599.html">freshmeat
article</a> goes into some depth about the problems they faced and how they
were handled. It's hard to tell if an rpm-based system, even using apt, can
be as cleanly upgradable as a Debian system, but we'll probably find out
soon. Debian is losing the edge of being the only distribution with an
Advanced Package Tool, on the other hand, we are set to gain some new
security features, including mirror authentication, and package
authentication, which Conectiva has added to apt, and another apt frontend
which they are writing. One very interesting quote from the article:
"<i>After full integration of the RPM patches into APT, it will have the
potential to become the standard package management frontend for
Linux</i>"
</p>

<p>
<b>Without much fanfare, Debian has grown from about 400 to 644 developers in
the past year.</b> Many of these developers, of course, are inactive, and many
others have just come through the new maintainer process and are still
learning. So it's not surprising that along with the regular grumbling about
the complexity of the new maintainer process, there is plenty of sentiment
among long-term developers that the title "Debian Developer" should be
reserved for members of an elite group who are "<i>committed, reliable, in
agreement with Debian's philosophy, and in it for the long haul</i>". That
last quote is from last week's Linux Weekly News, which included an
<a href="http://lwn.net/2000/1207/dists.php3">excellent summary</a> of
recent discussions concerning this topic.
</p>

<p>
A word of warning: 
<b>If you're tracking unstable, beware the upgrade to perl 5.6.</b> Some
large changes to the perl package (including no longer managing 
update-alternatives via /usr/bin/perl, which may make it more stable in
the long run) have <a href="https://bugs.debian.org/perl-5.6">broken many
upgrades</a>. Be prepared for problems like /usr/bin/perl not existing at
all, or debconf breaking in mysterious ways if you upgrade this week.
</p>

<p>
<b>Cleaning up woody's task packages</b> was the subject of a 
<a href="http://lists.debian.org/debian-policy-0012/msg00123.html">long
discussion</a>. While potato only shipped with a few screenfuls of task 
packages, the number of task packages in woody has exploded, and many of 
them are of doubtful utility to a new user who is installing Debian and wants
to use it for a specific task. Task packages aren't scaling as well as we had 
hoped, and there is a fair bit of confusion among the developers about what
exactly task packages should be used for. One solution involves putting 
a definition of what constitutes a valid task package into policy. Or we might
have to do away with the task system altogether and come up with some
<a href="http://lists.debian.org/debian-devel-0012/msg00927.html">alternate
method</a> that is more flexible and less prone to abuse.
</p>

#use wml::debian::weeklynews::footer

© 2014-2024 Faster IT GmbH | imprint | privacy policy