Debian Developers - about volatile.d.o/n

Author

about volatile.d.o/n

Andreas Barth

2004-10-08, 5:52 pm

Hi all,

we had some discussion about volatile, and I'm more and more considering to
pick this task up. I think some issues are quite obvious:

- packages should only go in in cooperation with the maintainers;

- volatile is not "just another place" for backports, but should only
contain changes to stable programs that are necessary to keep them
functional;

- Good candidates are clamav (including spin-offs), spamassassin,
chkrootkit;

- It should allow any administrator to "just use" volatile, as they "just
use" security.d.o, and they should be confident that nothing is broken by
that;

- for bugs, the normal debian bug tracking system should be used.

Some things are not so obvious:

- security support: There should be security support for volatile. However,
security.d.o is probably not the right place for that, and adding another
task to the security-team is IMHO also not the way to go. So, this needs
to be placed on the burden of the volatile team.

- "releases" of volatile: One could consider to seperate volatile into a
release and a staging area. An advantage would be that system
administrators would only need to update on some times. However, if we
restrict volatile, only upload required changes and don't have more than
10 packages in it, we don't need that.

- adding volatile packages to point releases: Though it may be seen as good
idea to add volatile packages at the next point release, this is
currently a no-go. I can see the good reasons for that, and I accept
them.

Two technical questions remain open for now, and needs to be solved
independend of the policy questions above.

- ftp-server: Should volatile be a "normal" part of the debian ftp-server,
or be setup independently (like e.g. security.d.o is)? Normal part would
of course be nicer for our users (and especially mirroring is free), but
requires some more work initially. However, this decision is in the
domain of the ftp-masters.

- architectures/buildd support (partly connected with ftp-server): Which
architectures should be supported? Perhaps starting with a smaller number
is a good idea, and adding more if they can cope with the updates.

I added http://volatile.debian.net/ to be a placeholder for the current
discussions.

Also, there is a archive present on
http://volatile.debian.net/debian-volatile, so if maintainers want to start
adding packages, they may contact me.

That's all for now. Comments and suggestions are welcome.

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Thomas Bushnell BSG

2004-10-08, 5:52 pm

Andreas Barth <aba@not.so.argh.org> writes:

> - volatile is not "just another place" for backports, but should only
> contain changes to stable programs that are necessary to keep them
> functional;

I think your proposal looks good, but I would like to see this
particular item fleshed out more fully. In particular, what kinds of
changes are being considered here?

In other words, would it count as "necessary" to say "new upstream
major release provides a new feature which keeps the virus scanner
useful, and also changes a bajillion unrelated things"?

In my book, the new virus definitions would be necessary, but not the
bajillion unrelated things, and I would like to see a rule that you
could not just put in the new upstream major release merely to get the
new virus definitions. That is, some kind of "minimal change to
preserve utility" rule, which might require the volatile-managers or
whoever to be Real Programmers and not just compilers.

Thomas

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andreas Barth

2004-10-08, 5:52 pm

* Thomas Bushnell BSG (tb@becket.net) [041008 18:25]:
> Andreas Barth <aba@not.so.argh.org> writes:

[vbcol=seagreen]
> I think your proposal looks good, but I would like to see this
> particular item fleshed out more fully. In particular, what kinds of
> changes are being considered here?
>
> In other words, would it count as "necessary" to say "new upstream
> major release provides a new feature which keeps the virus scanner
> useful, and also changes a bajillion unrelated things"?
>
> In my book, the new virus definitions would be necessary, but not the
> bajillion unrelated things, and I would like to see a rule that you
> could not just put in the new upstream major release merely to get the
> new virus definitions.

Agreed. So, this means: Backport the necessary changes. Sometimes, it's
just not enough to only update the virus scanner definitions, because
new functionality is needed to scan the files (just consider that a very
new archive format gets so popular that it needs to be supported, just
like zip now).

And, if there are changes that should be available on stable, but not be
the default (like e.g. the current spamassassin3), than they might get
in as new package, not disturbing the users of the old one, but giving
more choices. (Of course, even then, the package needs to be a bit more
mature than the curent spamassassin3, but that's a different thing. ;)

> That is, some kind of "minimal change to
> preserve utility" rule, which might require the volatile-managers or
> whoever to be Real Programmers and not just compilers.

Of course it requires them to be Real Programmers. The job is _not_
mechanically compiling something on stable.

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Thomas Bushnell BSG

2004-10-08, 5:52 pm

Andreas Barth <aba@not.so.argh.org> writes:

> Agreed. So, this means: Backport the necessary changes. Sometimes, it's
> just not enough to only update the virus scanner definitions, because
> new functionality is needed to scan the files (just consider that a very
> new archive format gets so popular that it needs to be supported, just
> like zip now).

Certainly; that makes sense. Good, I'm comfortable with this if it
can get written in to whatever official policy document in the right
way.

Thomas

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henning Makholm

2004-10-08, 5:52 pm

Scripsit Andreas Barth <aba@not.so.argh.org>

> Some things are not so obvious:

Should volatile include updates of packages such as debian-keyring?
debian-policy and developers-reference?

--
Henning Makholm "Al lykken er i ét ord: Overvægtig!"

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Stephen Gran

2004-10-08, 5:52 pm

This one time, at band camp, Henning Makholm said:
> Scripsit Andreas Barth <aba@not.so.argh.org>
>
>
> Should volatile include updates of packages such as debian-keyring?
> debian-policy and developers-reference?

I could see (possibly) debian-keyring, but policy and the reference
should be essentially frozen with the release - if policy X is in effect
at release time, all packages that are targeted at that release must use
policy X, unless I'm mistaken. The reference is, I suppose, less
frozen, but updates that address things like new packaging procedures
that are not present in stable would be problematic. Also, since these
are all arch: all packages, it's not like they're a big deal to just
grab if you need a newer copy for some reason.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------

Duncan Findlay

2004-10-08, 5:52 pm

On Fri, Oct 08, 2004 at 06:31:56PM +0200, Andreas Barth wrote:
> Agreed. So, this means: Backport the necessary changes. Sometimes, it's
> just not enough to only update the virus scanner definitions, because
> new functionality is needed to scan the files (just consider that a very
> new archive format gets so popular that it needs to be supported, just
> like zip now).

When spamassassin is upgraded, it's more than just the rules. Often
the method of parsing the message is changed -- leading to better
results, or support for different tests is added, etc. It would be
very difficult to only backport the appropriate changes, and the
result would be less stable than the version from which backporting
was taking place. On the other hand, each new version makes minor
changes to functionality. (Ignore 3.0.0 right now, it's got different
issues all together.) To require backported changes would simply be a
waste of effort and would defeat the purpose to a certain extent.
[vbcol=seagreen]
> And, if there are changes that should be available on stable, but not be
> the default (like e.g. the current spamassassin3), than they might get
> in as new package, not disturbing the users of the old one, but giving
> more choices. (Of course, even then, the package needs to be a bit more
> mature than the curent spamassassin3, but that's a different thing. ;)
>

Hmm..

--
Duncan Findlay

Martin Zobel-Helas

2004-10-08, 5:52 pm

Hi Andreas,

On Friday, 08 Oct 2004, you wrote:
>
> That's all for now. Comments and suggestions are welcome.
>

i would like to see some "policy", what, when and under which
circumstances gets included to volatile.d.n.

Is for example a package "whois" also a candidate for volatile?
Regestries change from time to time; i just consider .org changed within
the last 2,5 years...

Greetings
Martin
--
Martin Zobel-Helas PGP-Key: 0xF7AC3AF0

martin f krafft

2004-10-08, 5:52 pm

also sprach Martin Zobel-Helas <mhelas@helas.net> [2004.10.08.2019 +0200]:
> Is for example a package "whois" also a candidate for volatile?
> Regestries change from time to time; i just consider .org changed
> within the last 2,5 years...

I would say that a new version of whois could be included in
volatile if it becomes useless. I don't think anything should be in
volatile from the start.

And I certainly don't think it should be volatile.debian.*net*.

--
Please do not CC me when replying to lists; I read them!

.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system

Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

Andreas Barth

2004-10-08, 5:52 pm

* Henning Makholm (henning@makholm.net) [041008 19:50]:
> Scripsit Andreas Barth <aba@not.so.argh.org>

[vbcol=seagreen]
> Should volatile include updates of packages such as debian-keyring?
> debian-policy and developers-reference?

Pros: Well, these updates don't break any thing.
Cons: There is no need to treat them special, or do security updates.
Furthermore, it's easy to get them from backports.org.

Perhaps, adding some information about how easy it's to get them from
there would however be a good idea. (And, of course, if someone does a
"developers backport collection", including keyring,
developers-reference, dpatch, debhelper etc, this might also be a good
collection - but this has than a different target group than volatile.)

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Martin Zobel-Helas

2004-10-08, 5:52 pm

Hi Martin,

On Friday, 08 Oct 2004, you wrote:
> also sprach Martin Zobel-Helas <mhelas@helas.net> [2004.10.08.2019 +0200]:
>
> I would say that a new version of whois could be included in
> volatile if it becomes useless. I don't think anything should be in
> volatile from the start.
whois was just an example. i agree with you to not include all packages
from the begining in volatile. But we need to clarify under which
conditions such a package gets added.

>
> And I certainly don't think it should be volatile.debian.*net*.
agreed.

Martin
--
Martin Zobel-Helas PGP-Key: 0xF7AC3AF0

Andreas Barth

2004-10-08, 5:52 pm

* Duncan Findlay (duncf@debian.org) [041008 20:10]:
> On Fri, Oct 08, 2004 at 06:31:56PM +0200, Andreas Barth wrote:
[vbcol=seagreen]
> When spamassassin is upgraded, it's more than just the rules. Often
> the method of parsing the message is changed -- leading to better
> results, or support for different tests is added, etc. It would be
> very difficult to only backport the appropriate changes, and the
> result would be less stable than the version from which backporting
> was taking place. On the other hand, each new version makes minor
> changes to functionality.

Well, I think, it's in the end a case-by-case decision whether it's
better to take more or less a current package, und perhaps weed out some
definitly unrelated changes, or to take the old package and backport
some changes. Of course, in the end, the goal needs to be to make the
package as useable as possible - and of course, above all, do no harm,
and don't break things.

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andreas Barth

2004-10-08, 5:52 pm

* martin f krafft (madduck@debian.org) [041008 20:30]:
> And I certainly don't think it should be volatile.debian.*net*.

I'm open to changing this; however, for the start, it's easier with
debian.net - same as planet that also came to life as planet.debian.net.

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Marco d'Itri

2004-10-08, 5:52 pm

On Oct 08, martin f krafft <madduck@debian.org> wrote:

> I would say that a new version of whois could be included in
> volatile if it becomes useless. I don't think anything should be in
Is looking up .org domains in the wrong whois server enough to be
considered "useless"?
What about .pw domains?
What about IP addresses in 24.192.0.0/14?

--
ciao, |
Marco | [8429 imdW2er9vJsQ.]

martin f krafft

2004-10-08, 5:52 pm

also sprach Marco d'Itri <md@Linux.IT> [2004.10.08.2029 +0200]:
> Is looking up .org domains in the wrong whois server enough to be
> considered "useless"?

I found it rather useless in woody when the .org registrar changed.

> What about .pw domains?

What's that?

--
Please do not CC me when replying to lists; I read them!

.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system

Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

Andreas Barth

2004-10-08, 5:52 pm

Hi,

* Martin Zobel-Helas (mhelas@helas.net) [041008 20:25]:
> Is for example a package "whois" also a candidate for volatile?
> Regestries change from time to time; i just consider .org changed within
> the last 2,5 years...

Well, I would start small (and this means to exclude whois), and revisit
policy after some time to see what we should add or remove to it. And,
furthermore, why not do the next release of whois in a way that it's
possible to dynamically only update the zones (quite similar to the
virus scanners definitions), perhaps downloading from some debian site
once a month?

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andreas Barth

2004-10-08, 5:52 pm

* martin f krafft (madduck@debian.org) [041008 20:50]:
> also sprach Marco d'Itri <md@Linux.IT> [2004.10.08.2029 +0200]:
[vbcol=seagreen]
> I found it rather useless in woody when the .org registrar changed.

There are more packages that I consider rather useless than that should
be included in volatile - the criterion should be what almost everybody
considers useless.

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

martin f krafft

2004-10-08, 5:52 pm

also sprach Andreas Barth <aba@not.so.argh.org> [2004.10.08.2051 +0200]:
> Well, I would start small (and this means to exclude whois), and
> revisit policy after some time to see what we should add or remove
> to it. And, furthermore, why not do the next release of whois in
> a way that it's possible to dynamically only update the zones
> (quite similar to the virus scanners definitions), perhaps
> downloading from some debian site once a month?

There is some network tool in the archive that does something
similar. The name evades me right now... it asks with debconf how
often to download, kinda like a news client.

--
Please do not CC me when replying to lists; I read them!

.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system

Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

George Danchev

2004-10-08, 5:52 pm

On Friday 08 October 2004 22:03, martin f krafft wrote:
> also sprach Andreas Barth <aba@not.so.argh.org> [2004.10.08.2051 +0200]:
>
> There is some network tool in the archive that does something
> similar. The name evades me right now... it asks with debconf how
> often to download, kinda like a news client.

[pointer] that's slrn updating the group descriptions.

--
pub 4096R/0E4BD0AB 2003-03-18 <keyserver.bu.edu ; pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Francesco Paolo Lovergine

2004-10-08, 5:52 pm

I'll add a few my consideration already discussed in IRC with Andi and
others. Feel free to fill the gaps

On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote:
> Hi all,
>
> we had some discussion about volatile, and I'm more and more considering to
> pick this task up. I think some issues are quite obvious:
>
> - packages should only go in in cooperation with the maintainers;
>
> - volatile is not "just another place" for backports, but should only
> contain changes to stable programs that are necessary to keep them
> functional;
>

So no new styles of packaging: no dpatch introduction from scratch, for
instance.

> - Good candidates are clamav (including spin-offs), spamassassin,
> chkrootkit;
>

I'd add IDS like snort.

> - It should allow any administrator to "just use" volatile, as they "just
> use" security.d.o, and they should be confident that nothing is broken by
> that;
>

In some context volatile would be not useful, so separating the two
things is definitively The Good Thing To Do.

> - for bugs, the normal debian bug tracking system should be used.
>

.... adding a volatile tag probably as for experimental? But if nothing
would be broken by volatile pkgs, probably BTS is superfluous ;-)

>
> Some things are not so obvious:
>
> - security support: There should be security support for volatile. However,
> security.d.o is probably not the right place for that, and adding another
> task to the security-team is IMHO also not the way to go. So, this needs
> to be placed on the burden of the volatile team.
>

Unfortunately I think so too.

> - "releases" of volatile: One could consider to seperate volatile into a
> release and a staging area. An advantage would be that system
> administrators would only need to update on some times. However, if we
> restrict volatile, only upload required changes and don't have more than
> 10 packages in it, we don't need that.
>
> - adding volatile packages to point releases: Though it may be seen as good
> idea to add volatile packages at the next point release, this is
> currently a no-go. I can see the good reasons for that, and I accept
> them.
>

Indeed, I think we could have a few time post sarge release to buildup
the thing.

--
Francesco P. Lovergine

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andreas Barth

2004-10-08, 5:52 pm

Hi,

* Francesco Paolo Lovergine (frankie@debian.org) [041008 21:15]:
> On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote:

[vbcol=seagreen]
> ... adding a volatile tag probably as for experimental? But if nothing
> would be broken by volatile pkgs, probably BTS is superfluous ;-)

After sarge, the BTS is able to track versions.

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Nathanael Nerode

2004-10-08, 5:52 pm

Henning Makholm wrote:

> Scripsit Andreas Barth <aba@not.so.argh.org>
>
>
> Should volatile include updates of packages such as debian-keyring?

debian-keyring? Absolutely. Out-of-date versions of this are tediously
useless.

> debian-policy and developers-reference?
Probably not. Out-of-date versions of Policy are still useful for stable
releases (reflecting the version of policy in stable). Also the up-to-date
versions of these are easily used in their web form (unlike
debian-keyring).

--
This space intentionally left blank.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

George Danchev

2004-10-08, 5:52 pm

On Friday 08 October 2004 22:10, Francesco Paolo Lovergine wrote:
--cut--
>
> I'd add IDS like snort.

I'd add packages like ca-certificates. Perhaps it would be usefull to group
them in some manner...

--
pub 4096R/0E4BD0AB 2003-03-18 <keyserver.bu.edu ; pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Don Armstrong

2004-10-08, 5:52 pm

On Fri, 08 Oct 2004, Nathanael Nerode wrote:
> Henning Makholm wrote:
>
> debian-keyring? Absolutely. Out-of-date versions of this are
> tediously useless.

However, there are problems with updating the debian-keyring, and
deleted signatures and the ilk will keep files from being verifiable
if someone wants to check signatures on them. [I haven't made up my
mind if this is a good thing or not... but...]

Note as well, that you can trivially get the updated debian keyring by
pointing gpg at keyring.debian.org.

Don Armstrong

--
For a moment, nothing happened. Then, after a second or so, nothing
continued to happen.
-- Douglas Adams

http://www.donarmstrong.com http://rzlab.ucr.edu

Daniel Burrows

2004-10-08, 5:52 pm

Blars Blarson

2004-10-08, 5:52 pm

In article <20041008190333.GA19039@cirrus.madduck.net>
madduck@debian.org writes:
>
>--gKMricLos+KVdGMg
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>also sprach Andreas Barth <aba@not.so.argh.org> [2004.10.08.2051 +0200]:
>
>There is some network tool in the archive that does something
>similar. The name evades me right now... it asks with debconf how
>often to download, kinda like a news client.

hinfo optionally periodicly updates a couple of files using wget.
Never, once, weekly and monthy are the current options. (Daily would
be easy to add, but I considered it inappropriate for how often the
hinfo data changes.)

--
Blars Blarson blarson@blars.org
http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Francesco Paolo Lovergine

2004-10-08, 5:52 pm

On Fri, Oct 08, 2004 at 03:51:29PM -0400, Daniel Burrows wrote:
> On Friday 08 October 2004 11:51 am, Andreas Barth wrote:
>
> I generally have to resort to backports or unstable when installing Debian
> on recent hardware, because we don't update hardware drivers in stable.
> Would the kernel and X be candidates for volatile?
>

Uhm, if I'm remembering right at potato time we had kernel upgrades, at
least 2.2.17 -> 2.2.19. Unfortunately new kernels imply new big security
concerns in many cases. Anyway, kernel and X are not typical targets
for volatile: we are not proposing new stable releases, but only
very localized changes for a few programs which are inerently
subject to fast obsolescence (i.e. short-life applications).
For those kind of things backports.org is the right answer.

--
Francesco P. Lovergine

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

paddy

2004-10-08, 5:52 pm

Andi,

On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote:
> I think some issues are quite obvious:
>
> - packages should only go in in cooperation with the maintainers;
>
> - volatile is not "just another place" for backports, but should only
> contain changes to stable programs that are necessary to keep them
> functional;
>
> - Good candidates are clamav (including spin-offs), spamassassin,
> chkrootkit;
>
> - It should allow any administrator to "just use" volatile, as they "just
> use" security.d.o, and they should be confident that nothing is broken by
> that;
>
> - for bugs, the normal debian bug tracking system should be used.

It suddenly strikes me that the link between, say, clamav and spamassassin
is
co-evolving enemies

I think an explicit mention of the above as an ecological viewpoint is worthwhile
if only in this mail. (but only because I'm the only one to whom it wasn't
previously patently obvious

The balance of the risk of introducing bugs into such software has to be
seen in the context of a potentially large monoculture.

I would like to think that such a risk could be mitigated sufficiently to
enable the 'as-fast-as-possible' emphasis I have advocated, but I see that
good intentions alone cannot achieve that : substantial quantities of
'hard work' may eventually get me there.

Incidentally, Great work !

Regards,

Paddy

--
Perl 6 will give you the big knob. -- Larry Wall

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Stephen Gran

2004-10-08, 5:52 pm

This one time, at band camp, paddy said:
> Andi,
>
> On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote:
>
> It suddenly strikes me that the link between, say, clamav and spamassassin
> is
> co-evolving enemies
>
> I think an explicit mention of the above as an ecological viewpoint is worthwhile
> if only in this mail. (but only because I'm the only one to whom it wasn't
> previously patently obvious

This is precisely why I am interested in such a repository. the modern
internet is an arms race, and relying on tools several years out of date
is a poor solution. Thanks to Andi for your work - I will be in touch
about how to work with you on this.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------

Thomas Bushnell BSG

2004-10-08, 8:47 pm

Duncan Findlay <duncf@debian.org> writes:

> When spamassassin is upgraded, it's more than just the rules. Often
> the method of parsing the message is changed -- leading to better
> results, or support for different tests is added, etc. It would be
> very difficult to only backport the appropriate changes, and the
> result would be less stable than the version from which backporting
> was taking place. On the other hand, each new version makes minor
> changes to functionality. (Ignore 3.0.0 right now, it's got different
> issues all together.) To require backported changes would simply be a
> waste of effort and would defeat the purpose to a certain extent.

Nonsense. It would be harder work, and maybe there is nobody around
to do the hard work. But it is hardly impossible.

This is what stability is about. What you are calling for is
abandoning Debian's stability judgment to upstream's, in a situation
where upstream isn't making any stability promises at all.

So backport the appropriate changes only, and find programmers who can
do a good enough job not to screw it up and destabilize it.

Thomas

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Jesus Climent

2004-10-08, 8:47 pm

On Fri, Oct 08, 2004 at 08:19:24PM +0200, Martin Zobel-Helas wrote:
>
> Is for example a package "whois" also a candidate for volatile?
> Regestries change from time to time; i just consider .org changed within
> the last 2,5 years...

Perhaps... if it renders it unusable for getting whois answers...

--
Jesus Climent info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69

Gentlemen, you can't fight in here! This is the War Room.
--President Merkin Muffley (Dr. Strangelove)

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Jesus Climent

2004-10-08, 8:47 pm

On Fri, Oct 08, 2004 at 03:51:29PM -0400, Daniel Burrows wrote:
>
> I generally have to resort to backports or unstable when installing Debian
> on recent hardware, because we don't update hardware drivers in stable.
> Would the kernel and X be candidates for volatile?

I dont see any reason why not, if they can be marked as NotAutomatic.

--
Jesus Climent info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69

Why must I be surrounded by frickin' idiots?
--Dr. Evil (Austin Powers: International Man of Mystery)

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Jesus Climent

2004-10-08, 8:47 pm

On Fri, Oct 08, 2004 at 04:45:57PM -0700, Thomas Bushnell BSG wrote:
>
> Nonsense. It would be harder work, and maybe there is nobody around
> to do the hard work. But it is hardly impossible.
>
> This is what stability is about. What you are calling for is
> abandoning Debian's stability judgment to upstream's, in a situation
> where upstream isn't making any stability promises at all.
>
> So backport the appropriate changes only, and find programmers who can
> do a good enough job not to screw it up and destabilize it.

Just another thought... You think that people looking at the code to backport
a given set of features has a better clue about stability than the long time
experienced upstream programers?

I believe that a backport of many parts of the actual SA3 and even 2.64 or
earlier would result on a much more unstable version of SA (forked and
unsupported by upstream) than, say, 2.64. And what about security review? A
backported set of code integrated into an old core might have a better
integration? I doubt it.

I would rather have a 2.64 version in volatile (not a 3.0, right now) which
has been tested and used by thousands of users and postmasters than 2.20 or a
crippled version specific to Debian with all that possible but hard work done.

--
Jesus Climent info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69

It's a soldier's duty. You wouldn't understand.
--The Colonel (Akira)

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henrique de Moraes Holschuh

2004-10-08, 8:47 pm

On Fri, 08 Oct 2004, Thomas Bushnell BSG wrote:
> This is what stability is about. What you are calling for is
> abandoning Debian's stability judgment to upstream's, in a situation
> where upstream isn't making any stability promises at all.

I can speak only for myself, but I can guarantee you that this is *NOT* how
I will deal with Cyrus backports, and I am certainly not doing it for
amavisd-new as a co-maintainer, either.

There are packages and packages, and there are upstreams and upstreams.

If that means Cyrus IMAPd and amavisd-new are not good enough for
volatile.d.o, well, then I will keep the backports elsewhere (such as
in backports.org)...

But really, stability MUST be the name of the game for volatile.d.o (which
really suggests to me that we should have volatile/stable and
volatile/unstable, which do *NOT* track sid, but rather work a bit like what
sid -> testing does, but with grace times on the other of a month. And
always based on debian stable). This still has nothing to do with "no new
upstream versions".

> So backport the appropriate changes only, and find programmers who can
> do a good enough job not to screw it up and destabilize it.

Often, upstream IS good enough not to screw up and destabilize things.
Often, trying to backport things in pieces IS going to be much harder and
riskier (in stability terms) than doing a full new upstream version upgrade.
This is by no means the general rule, but those of us who have such an
upstream, know it.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Duncan Findlay

2004-10-09, 2:47 am

On Fri, Oct 08, 2004 at 04:45:57PM -0700, Thomas Bushnell BSG wrote:
> Duncan Findlay <duncf@debian.org> writes:
>
>
> Nonsense. It would be harder work, and maybe there is nobody around
> to do the hard work. But it is hardly impossible.

Well, it's possible, but it wouldn't be stable. A version that
consists only of backports is not going to have as many users, and as
a result will have little testing before releasing to
volatile.d.o. Unless you're saying you can find perfect programmers, a
version consisting only of backports will be less stable than a new
upstream version.

I can understand the logic to a certain extent when there is a small
set of changes, but it really doesn't work on a larger scale.

> This is what stability is about. What you are calling for is
> abandoning Debian's stability judgment to upstream's, in a situation
> where upstream isn't making any stability promises at all.

Not really. I'm just saying that there's necessarily a tradeoff and
you can't have the best of both worlds.

> So backport the appropriate changes only, and find programmers who can
> do a good enough job not to screw it up and destabilize it.

Given a large enough subset of upstream changes, any programmer will
"screw it up", especially in the absence of many users testing.

--
Duncan Findlay

Francesco Paolo Lovergine

2004-10-09, 2:47 am

On Sat, Oct 09, 2004 at 02:28:10AM +0200, Jesus Climent wrote:
> On Fri, Oct 08, 2004 at 03:51:29PM -0400, Daniel Burrows wrote:
>
> I dont see any reason why not, if they can be marked as NotAutomatic.
>

Due to versioned dependencies, that could be impractical for X, which has
a long list of reverse depends. I'd like to see in volatile just
as much as possible 'autoconsistent' pieces of software (to minimize
possibility of subtle breakage). Other things have already their home
in backports.org, at admin's risk. If you check d-kernel you we'll
also see that any new release of kernel would potentially cause
problems to a good deal of users. It's not a thing we could seriously
think to support IMHO.
Also, little is nice: thinking of having a looong list of (complicated
and interdependet) volatile packages would imply looong release cycles.
That's exactly the opposite we would gain with v.d.o|n.

--
Francesco P. Lovergine

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Kevin Mark

2004-10-09, 2:47 am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote:
> Hi all,
>
> we had some discussion about volatile, and I'm more and more considering to
> pick this task up. I think some issues are quite obvious:
>
> - packages should only go in in cooperation with the maintainers;
>
> - volatile is not "just another place" for backports, but should only
> contain changes to stable programs that are necessary to keep them
> functional;
>
> - Good candidates are clamav (including spin-offs), spamassassin,
> chkrootkit;
Hi Andres,
I've tried to follow the debate so far, but I'm not as knowledgable as a
DD, but I have some thoughts.
Packages like virus checkers seem to be
composed of 2 parts: the app program and the data where the data in
this case are virus sigs and the app is say clamav. And the 'volitile'
part is the virus sigs whereas the app (once it hits stable) shouldnt
change unless it warrents a 'security' update. So, volitile should be
for the data/virus sigs that need updating when new bugs hit the 'net.

Does this correspond with what others think?

also if the data conformed to the expected format for the version in
stable, would it have to go throught the same QA process
(expr-unstable-testing-stable)?
- -kev

- --

(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
....."Have you mooed today?"...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBZ4y3AWAAuqdWA9cRArSSAJ9RJRIqRuR/TObzU8fAds6E5xR6FACeMyS4
lkNMzUJn7sr6bEdFbZ9hjqc=
=zYVC
-----END PGP SIGNATURE-----

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Francesco Paolo Lovergine

2004-10-10, 5:54 pm

On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote:
> Packages like virus checkers seem to be
> composed of 2 parts: the app program and the data where the data in
> this case are virus sigs and the app is say clamav. And the 'volitile'
> part is the virus sigs whereas the app (once it hits stable) shouldnt
> change unless it warrents a 'security' update. So, volitile should be
> for the data/virus sigs that need updating when new bugs hit the 'net.
>

No, often such kind of programs need engine update. That's true for
both AV and antispam programs as well.

--
Francesco P. Lovergine

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Jesus Climent

2004-10-10, 5:54 pm

On Sat, Oct 09, 2004 at 08:47:27AM +0200, Francesco Paolo Lovergine wrote:
>
>
> Due to versioned dependencies, that could be impractical for X, which has
> a long list of reverse depends.

Sorry, with X i thought of "package X" instead of xserver-*. I meant for the
kernel, which in some cases it could be tagged non automatic for updates, so
that only the package is installed if the users wishes so. Making 2.6 kernels
available for woody could have been an scenario where this approach could have
work, except for the dependencies that the new kernel requires, but still is a
good example of a possibility.

J

--
Jesus Climent info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69

First came darkness, then came the strangers.
--Dr. Schreber (Dark City)

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Kevin Mark

2004-10-10, 5:54 pm

On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote:
> On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote:
>
> No, often such kind of programs need engine update. That's true for
> both AV and antispam programs as well.
>
> --
> Francesco P. Lovergine
Hi Francesco,
so:
the program = engine part + (some un-named part) ???
and the engine part and the data part are volitile

-Kev

--

(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
...."Have you mooed today?"...

Andreas Barth

2004-10-10, 5:54 pm

* Jesus Climent (jesus.climent@hispalinux.es) [041009 11:10]:
> I meant for the
> kernel, which in some cases it could be tagged non automatic for updates, so
> that only the package is installed if the users wishes so. Making 2.6 kernels
> available for woody could have been an scenario where this approach could have
> work, except for the dependencies that the new kernel requires, but still is a
> good example of a possibility.

Generally, new packages could be added to volatile, as long as there is
a very good usage of them. However, if I see how painful security
updates for the kernel currently are for the security team, I think we
should better reconsider this very good - because once a package is
added, we need to do security updates on it.

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Christoph Berg

2004-10-10, 5:54 pm

Re: Henning Makholm in <87hdp5nmjj.fsf@kreon.lan.henning.makholm.net>
>
> Should volatile include updates of packages such as debian-keyring?
> debian-policy and developers-reference?

Those who need these packages will run Sid anyway.

Christoph
--
cb@df7cb.de | http://www.df7cb.de/

Colin Watson

2004-10-10, 5:54 pm

On Fri, Oct 08, 2004 at 08:19:24PM +0200, Martin Zobel-Helas wrote:
> On Friday, 08 Oct 2004, you wrote:
>
> i would like to see some "policy", what, when and under which
> circumstances gets included to volatile.d.n.
>
> Is for example a package "whois" also a candidate for volatile?
> Regestries change from time to time; i just consider .org changed within
> the last 2,5 years...

That sounds like a candidate for a stable update to me, not volatile.

--
Colin Watson [cjwatson@debian.org]

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

martin f krafft

2004-10-10, 5:54 pm

also sprach Colin Watson <cjwatson@debian.org> [2004.10.09.1618 +0200]:
> That sounds like a candidate for a stable update to me, not
> volatile.

You mean an r-release? The problem with those is that they have too
much inertia to be able to provide fixes quickly. So then our users
will have an inoperable whois for a couple of weeks at least. This
is precisely the same situation as with AV scanners and precisely
the motivation behind v.d.o.

--
Please do not CC me when replying to lists; I read them!

.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system

Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

Stephen Gran

2004-10-10, 5:54 pm

This one time, at band camp, Kevin Mark said:
> On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote:
> Hi Francesco,
> so:
> the program = engine part + (some un-named part) ???
> and the engine part and the data part are volitile

In the case of clamav, most of the work of scanning is handled by
library functions, and these functions are called by the frontend
programs like clamscan, clamdscan, and the milter.

I think that spamassassin works much the saem way - most of the real
work is done by the PERL module Mail::Spamassassin, and the frontend
programs /usr/bin/spamassassin and spamc are an interface to using these
functions.

In addition to the engine itself, as has been noted, there are the data
sets that the engine uses to identify potential targets. In the case of
spamassassin, these are rules, and in the case of clamav, these are
virus signatures.

Right now, it is easy enough to get new data sets - the clamav suite
inculdes an updater for it's data, and spamassassin is easy to add new
rules to. The problem is updating the engine in a stable release.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------

paddy

2004-10-10, 5:54 pm

On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote:
> This one time, at band camp, Kevin Mark said:
>
<snip>
>
> Right now, it is easy enough to get new data sets - the clamav suite
> inculdes an updater for it's data, and spamassassin is easy to add new
> rules to. The problem is updating the engine in a stable release.

Indeed, there is a consensus that data updates with the volatility
of, say, virus scanner sigs belong firmly out-of-band.

Regards,

Paddy

--
Perl 6 will give you the big knob. -- Larry Wall

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

paddy

2004-10-10, 5:54 pm

On Fri, Oct 08, 2004 at 04:45:57PM -0700, Thomas Bushnell BSG wrote:
> Duncan Findlay <duncf@debian.org> writes:
>
>
> Nonsense. It would be harder work, and maybe there is nobody around
> to do the hard work. But it is hardly impossible.
>
> This is what stability is about. What you are calling for is
> abandoning Debian's stability judgment to upstream's, in a situation
> where upstream isn't making any stability promises at all.
>
> So backport the appropriate changes only, and find programmers who can
> do a good enough job not to screw it up and destabilize it.
>
> Thomas

Thomas,

The more the discussion goes on, the more value I see for this emphasis.

I started with clamav in mind as my archetypal example program.
But defining the class of programs, finding a form of words, is more
dificult than it at first appears. Take 'useless' for example. Elsewhere
in the thread <person> makes the point that hardware drivers could come
into the 'useless' category, and I know exactly what he means: I've been
there. But, I wouldn't want to have make X11 or kernels in volatile work:
sounds like a world of pain.

I got to thinking. In many ways the volatile conversation, is like the
one which goes 'can we have a five year EOL so that oracle will support us'.
Both deal with having a release cycle which is different from the status
quo, and other general discussion on that subject is often heard.

The appearance of volatile.d.n suggests to me that Debian is continuing to
grow in a healthy way. Perhaps deepfreeze.d.n (or whatever) is waiting in
the wings, or other things.

I could imagine maintaining clamav against a 5 year old codebase
(I do something not so different to that now). clamav is in C, and
reasonably self-contained. The version skew doesn't really get to you.
The PERL based stuff is a bigger problem.

I guess I'm saying two things:

Ultimately the general rule _always_ has be

'backport the appropriate changes only'.

Perhaps maintainers of candidates for volatile will want to take a
cautionary second to imagine what it might be like to be working
against that five-year-old codebase.

And the reason I'm saying these things is that I think that volatile
and main archive, 'deepfreeze-or-whatever' or whatever comes along
will be at their best if they all work together, rather than being
seperate little islands.

Regards,

Paddy

--
Perl 6 will give you the big knob. -- Larry Wall

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

paddy

2004-10-10, 5:54 pm

On Sat, Oct 09, 2004 at 05:13:49PM +0100, paddy wrote:
> Elsewhere
> in the thread <person> makes the point that hardware drivers could come
> into the 'useless' category, and I know exactly what he means: I've been
> there.

And seconds after I pressed the send button I got that horrible sinking feeling.

s/<person>/Daniel Burrows/

I'm sorry Daniel, no offense intended.

Regards,

Paddy

--
Perl 6 will give you the big knob. -- Larry Wall

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Thomas Bushnell BSG

2004-10-10, 5:54 pm

Jesus Climent <jesus.climent@hispalinux.es> writes:

> Just another thought... You think that people looking at the code to backport
> a given set of features has a better clue about stability than the long time
> experienced upstream programers?

I expect the Debian maintainers of such a package to understand the
code very well themselves, because that would be a necessary part of
the job.

The upstream maintainers might well have a good clue about stability,
but the point is that they haven't promised anything about stability.
Stability means not changing features and interactions with other
parts of the system, and I don't think they worry about that much at
all.

Thomas

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Kevin Mark

2004-10-10, 5:54 pm

On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote:
> This one time, at band camp, Kevin Mark said:
>
> In the case of clamav, most of the work of scanning is handled by
> library functions, and these functions are called by the frontend
> programs like clamscan, clamdscan, and the milter.
Hi Stephen,

so,
email
|
\/
{lib}clamav->clamav{frontend}<-clamav-{data}
|
\/
mbox

the api for {lib} and {frontend} must be in sync.
update {lib} api and then you would have to update all {frontends}.
does not sound like 'stable' policy?

the data format used in {data} and read by the {lib} must be in sync.
update the {lib} may lead to a change in data format which would
probably lead to an api change which would mean updates to all
{frontends}. ugh!

would it be good to backport new dataformat to 'stable' dataformat or
risk having to fix {lib} and {frontend}s? then they would be 'unstable'
and need QA?
clam-data has an updated but not all similar frontends do.
what is done for others that do not have 'freshclam'?

what is the diff between
stable.update,security.update,volitile.update?
enquiring minds what to know? hope this is not too OT!
-Kevin

--

(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
...."Have you mooed today?"...

Kevin Mark

2004-10-10, 5:54 pm

On Sat, Oct 09, 2004 at 04:37:14PM +0100, paddy wrote:
> On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote:
> <snip>
>
> Indeed, there is a consensus that data updates with the volatility
> of, say, virus scanner sigs belong firmly out-of-band.

Hi Paddy,
so that leaves libs and frontends (at least for clamav)
but I thought the ideas was to protect against virus threats?

if its out-of-band (not in debian control) than the only thing that
would seem reasonable is to convert between any new data format and the
data format used in stable.

current stable=
no changes to package = stable system with security left to user

with volitile=backport data format=
stable system with some new data to improve security somewhat

with volitile=backport lib, frontends,data?=
possible unstable system with possibly up-to-data security

Dont take the above as anything other than my overexagerated guess.
I'm just thinking it through to see if I can squeeze this into me wee
brain!
-Kev
--

(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
...."Have you mooed today?"...

Jesus Climent

2004-10-10, 5:54 pm

On Sat, Oct 09, 2004 at 11:44:41AM +0200, Andreas Barth wrote:
>
> Generally, new packages could be added to volatile, as long as there is
> a very good usage of them. However, if I see how painful security
> updates for the kernel currently are for the security team, I think we
> should better reconsider this very good - because once a package is
> added, we need to do security updates on it.

I am not implying it has to be, but in the long run it can be a good candidate
to add value to an otherwise old (yeah, stable too) distribution.

--
Jesus Climent info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69

That's thirty minutes away. I'll be there in ten.
--Wolf (Pulp Fiction)

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

paddy

2004-10-10, 5:54 pm

On Sat, Oct 09, 2004 at 03:54:11PM -0400, Kevin Mark wrote:
> On Sat, Oct 09, 2004 at 04:37:14PM +0100, paddy wrote:
>
> Hi Paddy,
> so that leaves libs and frontends (at least for clamav)
> but I thought the ideas was to protect against virus threats?
>
> if its out-of-band (not in debian control) than the only thing that
> would seem reasonable is to convert between any new data format and the
> data format used in stable.

maybe there is a place for this, but my understanding is the evolution
of data formats is coupled to changes in the scaning engine and backward
compatibility is maintained upstream for as long as the upstream
maintainers deem reasonable. It may be that engines will eventually
evolve to the point where these changes happen on the timescale of a
debian stable release, then again it may be in the nature of the problem
that they never will. Noone seems to be suggesting that the former is on
the immediate horizon (as they are for mozilla for example).
I am arguing the latter.

> current stable=
> no changes to package = stable system with security left to user

for clamav, i would hope security.d.o to cover as usual.
and virus scanning is not generally about protecting linux hosts.
So I see it as a question of function rather than security, in this case.

> with volitile=backport data format=
> stable system with some new data to improve security somewhat

maybe, see above.

> with volitile=backport lib, frontends,data?=
> possible unstable system with possibly up-to-data security

clamav is a really good example of a very self-contained, at least in
some setups. two pipes, no privs (someone corrrect me if I'm wrong).
In the case of clamav, what i believe is at issue is not the stability or
security of whole individual systems (possibly the clamav function) but
importantly the stability of the archive, that system.

> Dont take the above as anything other than my overexagerated guess.
> I'm just thinking it through to see if I can squeeze this into me wee
> brain!

It's great to talk with you.
The more I look at it, the more of the complexity of the problem I see.
I hope you can find plenty more room in there ;)

Regards,

Paddy

> -Kev
> --
>
> (__)
> (oo)
> /------\/
> / | ||
> * /\---/\
> ~~ ~~
> ...."Have you mooed today?"...

--
Perl 6 will give you the big knob. -- Larry Wall

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

paddy

2004-10-10, 5:54 pm

On Sat, Oct 09, 2004 at 10:48:15PM +0100, paddy wrote:
> maybe there is a place for this, but my understanding is the evolution
> of data formats is coupled to changes in the scaning engine and backward
> compatibility is maintained upstream for as long as the upstream
> maintainers deem reasonable.

It occurs to me that it may be possible to do some backporting of
signatures (as distinct from a simple mechanical translation).
No doubt Thomas will provide encouragement, if you are inclined to
undertake such a sisyphean task. Peering into my crystal ball
I see a man with a soldering iron handing you a medal emblazoned
with the words 'Real Programmer'.

Regards,

Paddy
--
Perl 6 will give you the big knob. -- Larry Wall

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

paddy

2004-10-10, 5:54 pm

On Sat, Oct 09, 2004 at 03:44:13PM -0400, Kevin Mark wrote:
> On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote:
> Hi Stephen,
>
> so,
> email
> |
> \/
> {lib}clamav->clamav{frontend}<-clamav-{data}
> |
> \/
> mbox

Apologies Stephen, you will need to correct me, but here goes:

email
|
V
stuff
|
libs -{api.3}------ {api.4}
| |
V V
sigs -{api.1}-> engine -{api.2}-> frontend
|
{api.4 or 5}
|
V
stuff...

> the api for {lib} and {frontend} must be in sync.
> update {lib} api and then you would have to update all {frontends}.
> does not sound like 'stable' policy?

if {api.2} changes then presumably frontend must change.

> the data format used in {data} and read by the {lib} must be in sync.
> update the {lib} may lead to a change in data format which would
> probably lead to an api change which would mean updates to all
> {frontends}. ugh!

I imagine it is quite possible for {api.1} to change without impacting
{api.2}. Indeed, I suppose that to be part of the value of {api.2}.
If it actually exists. I confess, I made it up.

> would it be good to backport new dataformat to 'stable' dataformat or
> risk having to fix {lib} and {frontend}s? then they would be 'unstable'
> and need QA?

see my previous mail.

> clam-data has an updated but not all similar frontends do.
> what is done for others that do not have 'freshclam'?

This is in flux, and part of the problem being discussed. See for
instance discussion of snort rules and oinkmaster, or nessus-plugins.

> what is the diff between
> stable.update,security.update,volitile.update?
> enquiring minds what to know? hope this is not too OT!

Don't know, but I guess perhaps this is a question for Andi.

Regards,

Paddy

> -Kevin
>
>
> --
>
> (__)
> (oo)
> /------\/
> / | ||
> * /\---/\
> ~~ ~~
> ...."Have you mooed today?"...

no, why do you think I should ???

--
Perl 6 will give you the big knob. -- Larry Wall

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

paddy

2004-10-10, 5:54 pm

Here I go, replying to myself again ...

On Sat, Oct 09, 2004 at 10:48:15PM +0100, paddy wrote:
> clamav is a really good example of a very self-contained, at least in
> some setups. two pipes, no privs (someone corrrect me if I'm wrong).
> In the case of clamav, what i believe is at issue is not the stability or
> security of whole individual systems (possibly the clamav function) but
> importantly the stability of the archive, that system.

Even if I'm not oversimplifying, I'm assuming that compromise of a
clamav process could give access to any local exploits available through
available system calls. I take it that stable and security.d.o
pick up the tab for this. Which makes me wonder: I seem to recall
that maintenance of linux kernels has tended to drop covering local
holes after a period on old kernels. I take it stable has this
covered, but it would be a consideration for any potential deep-freezers,
and is at least a box to check for volatile.

Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Sven Mueller

2004-10-10, 5:54 pm

Jesus Climent [u] wrote on 09/10/2004 02:28:

> On Fri, Oct 08, 2004 at 03:51:29PM -0400, Daniel Burrows wrote:
>
>
> I dont see any reason why not, if they can be marked as NotAutomatic.

I certainly see reason not to include X in colatile. X pulls in xlibs,
and xlibs is depended on by a _huge_ amount of programs if I'm not
mistaken. It is near impossible to tell wether an X upgrade might break
things or not.

As for the kernel: If I were a volatile RM-aequivalent, I might consider
getting the kernel into v.d.o, even though it is a huge beast, it
usually either breaks completely on some specific system or it doesn't
break anything. But I'm not sure about this.

regards,
Sven

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Stephen Gran

2004-10-10, 5:54 pm

This one time, at band camp, Kevin Mark said:
> On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote:
> Hi Stephen,
>
> so,
> email
> |
> \/
> {lib}clamav->clamav{frontend}<-clamav-{data}
> |
> \/
> mbox

This might be a more helpful diagram:

email
|
MTA<--->clam frontend
| |
| library<-->data set (sigs)
mbox

Clam doesn't scan email in isolation - it's called by an MTA or a glue
application like amavis. The fact that the underlying library functions
or data sets have changed internally should not matter to the caller, so
long as the front ends have the same API. There is one application I
see outside of the clamav suite that links against libclamav1 directly,
and that will take careful coordination - all the others rely on the API
provided by frontends and will not break so long as the API remains
constant.

> would it be good to backport new dataformat to 'stable' dataformat or
> risk having to fix {lib} and {frontend}s? then they would be 'unstable'
> and need QA?

Not really - clam is dropping the ability to read unsigned datasets, and
while it would be technically possible to recreate signed signature sets
in an older format, the delay introduced by doing so would obviate the
advantage of having automatic updates. Also, clam currently relies on a
worldwide system of mirrors, each of which currently does about 10G of
traffic/month just for the clam updates. Where do you propose we host the
single mirror that will update all of the sarge installs that can't use
the newer data format? I don't have the bandwidth and I don't think
it's practical for p.d.o.

> what is the diff between
> stable.update,security.update,volitile.update?
> enquiring minds what to know? hope this is not too OT!
> -Kevin

My understanding is that stable-proposed-updates is for packages that
maintainers would like to see in the next point release, security is for
the security team and contains fixes for packages mentioned in DSA's,
and volatile is intended for packages that need to update more
frequently than point releases allow, but are not directly security
problems, and so are not the arena of the security team.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------

Florian Weimer

2004-10-10, 5:54 pm

* Andreas Barth:

> - volatile is not "just another place" for backports, but should only
> contain changes to stable programs that are necessary to keep them
> functional;

Can volatile receive critical updates which are usually not applied to
stable because backports are not available for some reason?

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Frank Küster

2004-10-11, 2:48 am

martin f krafft <madduck@debian.org> schrieb:

> also sprach Marco d'Itri <md@Linux.IT> [2004.10.08.2029 +0200]:
>
> I found it rather useless in woody when the .org registrar changed.

I'd say it is a bug in whois to ship this information in the binary,
instead of some file in /etc/.

Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

Matthew Garrett

2004-10-11, 7:50 am

Christoph Berg <cb@df7cb.de> wrote:
> Re: Henning Makholm in <87hdp5nmjj.fsf@kreon.lan.henning.makholm.net>
>
> Those who need these packages will run Sid anyway.

I'd sincerely hope not. The fact that few developers run stable is a
contributing factor to the lack of motiviation towards releasing. I
don't think many people understand just how old stable currently is.
Where possible, I think developers should be encouraged to run at least
one stable box...

--
Matthew Garrett | mjg59-chiark.mail.debian.devel@srcf.ucam.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Florian Weimer

2004-10-11, 7:50 am

* Andreas Barth:

>
> Are you speaking about mozilla? ;)

Mozilla, GnuPG, and maybe even php 4, depending on sarge's lifetime.
Other complex packages can easily enter this state, too, especially
when sarge has been around for a year or two.

Actually, Mozilla's situation is beginning to look rather promising.
The distributor community seems to pick up the challenge and issue
patches. Of course, if we release 1.6 with sarge (a version that is
officially unsupported by upstream), we might not be able to profit
from this development.

> However, in the long run, I think you're right about adding newer
> packages if they fix security issues, and we can't fix them otherwise.
> But I think it needs more than just some consideration how to do this in
> a non-breaking way.

I agree that this has to be decided on a case-by-case basis.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Matthew Garrett

2004-10-11, 7:50 am

Martin Zobel-Helas <mhelas@helas.net> wrote:

> i would like to see some "policy", what, when and under which
> circumstances gets included to volatile.d.n.

The most sensible policy would be a case by case consideration. Some
packages can sanely have the desired features backported [1], and some
can't [2]. It's possible that we /could/ write policy that would
actually be able to differentiate between the two cases, but it's fairly
likely that it would just end up devolving into flamewars about corner
cases or misclassification. I'd suggest a team of reasonable people who
we trust to make the decisions and liase with package maintainers as
appropriate. It's much less effort and it involves much less
unhappiness.

[1] whois would probably be a good example - if the set of whois servers
is suddenly altered, the right thing to do is to change the list rather
than update to the latest version

[2] If sensible spamassassin functionality is based on a new parsing
engine, then backporting that functionality to the old parsing engine
may be impossible and is certainly going to involve a sufficiently large
amount of new and untested code that any claims about enhanced stability
aren't going to be massively convincing
--
Matthew Garrett | mjg59-chiark.mail.debian.devel@srcf.ucam.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Matthew Garrett

2004-10-11, 7:50 am

Daniel Burrows <dburrows@debian.org> wrote:

> I generally have to resort to backports or unstable when installing Debia=
> n=20
> on recent hardware, because we don't update hardware drivers in stable. =20
> Would the kernel and X be candidates for volatile?

I think those are arguments for making releases more quickly, rather
than anything else. It's a subtley different argument to the volatile
one.

--
Matthew Garrett | mjg59-chiark.mail.debian.devel@srcf.ucam.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

paddy

2004-10-11, 7:50 am

On Mon, Oct 11, 2004 at 10:42:58AM +0100, Matthew Garrett wrote:
> Daniel Burrows <dburrows@debian.org> wrote:
>
>
> I think those are arguments for making releases more quickly, rather
> than anything else.

I'm not sure about that, graphics hardware, for example, is far faster moving
than stable. And there are forces pulling both ways on the stable release
cycle.

The kernel and X are both at least somewhat modular, how unrealistic
is it to think in terms of backporting just the drivers ? And would that
be better?

> It's a subtley different argument to the volatile
> one.

Agreed. Not useless, simply not useful. ;)

Most of us must encounter this, I think in terms of 'choose your poison'.

Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

paddy

2004-10-11, 7:50 am

Matthew Garrett

2004-10-11, 7:50 am

paddy <paddy@panici.net> wrote:
> On Mon, Oct 11, 2004 at 10:42:58AM +0100, Matthew Garrett wrote:
>
> I'm not sure about that, graphics hardware, for example, is far faster moving
> than stable. And there are forces pulling both ways on the stable release
> cycle.

If we aimed at a new stable release about once a year (which obviously
requires providing support for more than one release at once, but
still), that would be much less of a problem.

> The kernel and X are both at least somewhat modular, how unrealistic
> is it to think in terms of backporting just the drivers ? And would that
> be better?

Adding new drivers is usually fairly easy and probably wouldn't cause
any problems. Backporting more recent versions of existing drivers isn't
desperately hard, but newer drivers frequently cause regressions in
existing hardware support. Without going through a full release cycle,
it's difficult to track down whether or not something has broken.

--
Matthew Garrett | mjg59-chiark.mail.debian.devel@srcf.ucam.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Frank Küster

2004-10-11, 7:50 am

Matthew Garrett <mgarrett@chiark.greenend.org.uk> schrieb:

> Christoph Berg <cb@df7cb.de> wrote:
>
> I'd sincerely hope not. The fact that few developers run stable is a
> contributing factor to the lack of motiviation towards releasing. I
> don't think many people understand just how old stable currently is.
> Where possible, I think developers should be encouraged to run at least
> one stable box...

Which would be painful to use. Some backports - e.g. Adrian Bunk's
collection - are really advisable. But even then you know how old woody
is.=20

Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer

paddy

2004-10-11, 7:50 am

On Mon, Oct 11, 2004 at 11:42:57AM +0100, Matthew Garrett wrote:
> paddy <paddy@panici.net> wrote:
>
> If we aimed at a new stable release about once a year (which obviously
> requires providing support for more than one release at once, but
> still), that would be much less of a problem.

I'm wondering if the long-term solution may be to extend security.d.o support
for some important subset (say standard, for the sake of argument), allowing
the main release cycle a little more freedom to float to a different level
if that is where it wants to go.

>
> Adding new drivers is usually fairly easy and probably wouldn't cause
> any problems. Backporting more recent versions of existing drivers isn't
> desperately hard,

That's good ...

> but newer drivers frequently cause regressions in
> existing hardware support. Without going through a full release cycle,
> it's difficult to track down whether or not something has broken.

If all drivers are in one large package, then this is a huge problem, but
if they can be packaged individually, much less so I think. Even without
individual packaging, volatile might one-day still make a home for such
things (but I _won't_ be helping!

It it easy to imagine how one might admit a single driver onto the
volatile archive ...

Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

paddy

2004-10-11, 7:50 am

Andi,

On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote:
> - It should allow any administrator to "just use" volatile, as they "just
> use" security.d.o, and they should be confident that nothing is broken by
> that;

It would be great to get some clarification of this.

Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andreas Barth

2004-10-11, 7:50 am

* paddy (paddy@panici.net) [041011 12:55]:
> On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote:
[vbcol=seagreen]
> I would like 'must' keep them functional: IOW, voltaile is prepared to
> drop packages from volatile that are, for whatever reason, unable to keep
> up with the purpose. It would be sad if volatile ended up containing
> useless packages!

Of course we need to reserve the right to drop packages - but, doing
that would still be bad. Adding a package to volatile means for me that
we are very confident that we can support it till the current debian
major release is archived. If we can't do that, we shouldn't have added
it in the first place.

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

paddy

2004-10-11, 7:50 am

On Mon, Oct 11, 2004 at 02:02:47PM +0200, Andreas Barth wrote:
> * paddy (paddy@panici.net) [041011 12:55]:
>
>
> Of course we need to reserve the right to drop packages - but, doing
> that would still be bad. Adding a package to volatile means for me that
> we are very confident that we can support it till the current debian
> major release is archived. If we can't do that, we shouldn't have added
> it in the first place.

Hmm, deja vu ;)

What happens to packages that become orphaned?

Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andreas Barth

2004-10-11, 7:50 am

* paddy (paddy@panici.net) [041011 15:35]:
> On Mon, Oct 11, 2004 at 02:02:47PM +0200, Andreas Barth wrote:
[vbcol=seagreen]
> Hmm, deja vu ;)
>
> What happens to packages that become orphaned?

The same that happens with them in stable. The volatile team has to keep
care of them till the current debian major release is archived.

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

paddy

2004-10-15, 9:31 pm

On Mon, Oct 11, 2004 at 03:37:21PM +0200, Andreas Barth wrote:
> * paddy (paddy@panici.net) [041011 15:35]:
>
>
> The same that happens with them in stable. The volatile team has to keep
> care of them till the current debian major release is archived.

Given that the volatile team is the gatekeeper to the volatile archive,
this is an excellent approach: packages are unlikely to get in too easily.

It's also a big commitment: kudos once again for stepping up to the plate.

Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henning Makholm

2004-10-15, 9:31 pm

Scripsit Florian Weimer <fw@deneb.enyo.de>

[vbcol=seagreen]
> Mozilla, GnuPG, and maybe even php 4, depending on sarge's lifetime.
> Other complex packages can easily enter this state, too, especially
> when sarge has been around for a year or two.

I would advise not trying to overloade volatile with too many
meanings. A backport of a new Mozilla release is something vastly
different from new rules for a spam filter, and I see little value in
lumping them together in the same add-on repository. I would like to
see a volatile with a very strict mandate:

1. Volatile is a means for *pushing* updates to stable
installations, where such updates are necessary for *preserving*
the utility of packages due to changes of the outside world.

2. "Necessary for preserving the utility" should be judged under
the assumption that the machine that runs stable does not itself
change. (I.e., appeals to "this is needed for modern hardware"
don't count).

3. No update pushed through volatile should ever change any
user interfaces or programmatic interface. (How paranoid
developers are expected to be in ensuring this is negotiable,
but it must at least be the *goal* that no interfaces change.)

The goal should be that I, as a user, can add volatile to my
sources.list and periodically do an apt-get upgrade - without risking
to suddenly have my web browser updated to a new major release where
it starts behaving differently, all my users' preferences get out of
kilter, etc. If I run a web browser on a stable machine, it is because
I am satisfied with its behavior and capabilities. If I want a newer
one, I can go to a regular backports repository and pick one by hand.
I do not want to get a new version pushed at me simply because it
becomes available. If I wanted that kind of behavior I would run
testing or unstable, not stable.

An update of mozilla-browser would be appropriate for volatile if it
did not change the upstream codebase, but, say, updated the default
SSL root certificate set in response to announcements from a
well-known CA.

An update that fixed the default style sheet to include new tags
from XHTML 2.1, assuming that it was possible without code changes,
would be borderline. Anything more involved than that - no thanks.

--
Henning Makholm "Punctuation, is? fun!"

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andreas Barth

2004-10-15, 9:31 pm

* Henning Makholm (henning@makholm.net) [041011 18:30]:
> The goal should be that I, as a user, can add volatile to my
> sources.list and periodically do an apt-get upgrade - without risking
> to suddenly have my web browser updated to a new major release where
> it starts behaving differently, all my users' preferences get out of
> kilter, etc.

I think this is one of the most important statements - and I think it
describes our policy quite well.

I could however see the possiblity to add a new package "mozilla1.7",
that users can optionally install. However, I also won't like it.

cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

John Hasler

2004-10-15, 9:31 pm

Henning Makholm writes:

> 1. Volatile is a means for *pushing* updates to stable