headers
brian m. carlson | 1 Feb 2011 02:43
Gravatar

Bug#611698: nodejs: conflicts with package node needlessly

Package: nodejs
Version: 0.2.6-1
Severity: serious
Tags: experimental

It appears that nodejs in experimental has acquired a Conflicts with
node.  According to the changes file for that release:

   * Use upstream binary names for node and node-waf,
     conflicts with node package. (Closes: #597571)

I still don't believe that is allowed by Debian Policy.  Section 10.1
states:

     Two different packages must not install programs with different
     functionality but with the same filenames.  (The case of two programs
     having the same functionality but different implementations is handled
     via "alternatives" or the "Conflicts" mechanism.  See Section 3.9,
     `Maintainer Scripts' and Section 7.4, `Conflicting binary packages -
     `Conflicts'' respectively.) If this case happens, one of the programs
     must be renamed.  The maintainers should report this to the
     `debian-devel' mailing list and try to find a consensus about which
     program will have to be renamed.  If a consensus cannot be reached,
     _both_ programs must be renamed.

#597571 had been marked wontfix, but then was mysteriously closed in
experimental.  If this isn't in contravention of Debian Policy (which is
possible, I suppose), then what's been done to resolve it so it isn't
should be put in README.Debian or NEWS.Debian.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thijs Kinkhorst | 1 Feb 2011 10:06
Picon
Favicon

Re: A request for those attending key signing parties

On Mon, January 31, 2011 21:18, Martin Zobel-Helas wrote:
> a more theoretical question quite related to this:
>
> If one plans to have the key replaced in the keyring, and we have a
> fellow DD in the keyring who's only trust path to other Debian
> Developers goes via that key (this might become a real scenario when we
> do a bigger round of key replacements) will that key replacement really
> happen? Thus CCing keyring maintainers.

(I'm not a keyring maintainer.)

Currently connectedness has only been used to decide on entry into the
keyring. In a similar scenario, if you are signed by just one DD and that
DD retires from Debian, you are not removed from the keyring, even though
you're no longer connected to other DD's by trust paths. And that is not a
problem, because the process is used to establish identity. Your identity
has been established upon entry, and this fact is not lost when
connectedness of your key is reduced. Thus it's not essential to keep the
keys internally connected.

Cheers,
Thijs

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Archive: http://lists.debian.org/906938246402b2893e33b381b2fe3747.squirrel <at> wm.kinkhorst.nl
Permalink | Reply | 0 comments |
headers
Thijs Kinkhorst | 1 Feb 2011 10:12
Picon
Favicon

Re: Upstream "stable" branches and Debian freeze

On Mon, January 31, 2011 18:09, Christian PERRIER wrote:
> However, upstream's policy in their "stable" branches is alway to only
> fix "important" bugs (they don't call them this way...but the
> definition is fairly close to Debian's). So, *in the case of samba*, I
> can guarantee that the user's (indeed sysadmin's) experience is much
> improved if (s)he can follow the upstream minor releases.

In the past such things have not been allowed with the argumentation that
even though stable may contain bugs, users rely on the behaviour that
stable has. They may know about a bug but may have worked around it (and
the update may break the workaround) or they do not know about a bug but a
fix for it may break a previously functional system. And of course as we
all know: bugfixes are not zero-risk and do have chances on new bugs being
introduced.

Being completely bug-free would be nice, but is probably unachievable. I
think there's something to say for the predictability of a release: it may
not be perfect, but once installed and tested it will keep working.

Cheers,
Thijs

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Archive: http://lists.debian.org/4edb1dc090de6330490ab7f897785b9f.squirrel <at> wm.kinkhorst.nl
Permalink | Reply | 6 comments |
headers
Petter Reinholdtsen | 1 Feb 2011 10:58

Re: CPE lists was Re: Equivalent packages between Linux distributions


[Silvio Cesare]
> I created an automatically generated CPE list for Fedora13
> packages. It only has 300 or so packages in it, but this will
> improve as say Debian increase the list of packages they track (they
> only track 1100 or so currently).
>
> https://github.com/silviocesare/Equivalent-Packages/blob/master/CPE/Fedora13.CPE.generated

Very interesting.  I created the CPE entries for Debian manually, by
comparing the set of affected packages reported in the CVE database
for Debian and NVD.  Perhaps something similar could be done for
Fedora, assuming the project track CVEs in a structured way?

Note that there are several duplicate CPE entries used by NVD.  A list
of the ones I have identified so far is in data/CPE/aliases.

Note that there is a bug in your list.  xen is claimed to be
grub-legacy.  Perhaps check your code?

Happy hacking,
--

-- 
Petter Reinholdtsen
Permalink | Reply | 0 comments |
headers
Henrique de Moraes Holschuh | 1 Feb 2011 12:41
Picon
Favicon

Re: Upstream "stable" branches and Debian freeze

On Tue, 01 Feb 2011, Thijs Kinkhorst wrote:
> On Mon, January 31, 2011 18:09, Christian PERRIER wrote:
> > However, upstream's policy in their "stable" branches is alway to only
> > fix "important" bugs (they don't call them this way...but the
> > definition is fairly close to Debian's). So, *in the case of samba*, I
> > can guarantee that the user's (indeed sysadmin's) experience is much
> > improved if (s)he can follow the upstream minor releases.
> 
> In the past such things have not been allowed with the argumentation that
> even though stable may contain bugs, users rely on the behaviour that
> stable has. They may know about a bug but may have worked around it (and
> the update may break the workaround) or they do not know about a bug but a
> fix for it may break a previously functional system. And of course as we
> all know: bugfixes are not zero-risk and do have chances on new bugs being
> introduced.

It is a good thing that we are actually able to learn, and move forward
then, isn't it?

Some upstreams do so much regression testing and are so strict, that
you'd actually be doing a disservice to your users if you don't track
their stable branch during Debian stable lifetime.

> Being completely bug-free would be nice, but is probably unachievable. I
> think there's something to say for the predictability of a release: it may

You can just unplug it from the net and never update, if you want that
(and if you're going to do that, be smart and use read-only media for
the invariant parts of the system already): We've had several
regressions due to security fixes.  While those are not frequent,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Jackson | 1 Feb 2011 14:11
Picon

Re: Upstream "stable" branches and Debian freeze

Thijs Kinkhorst writes ("Re: Upstream "stable" branches and Debian freeze"):
> In the past such things have not been allowed with the argumentation that
> even though stable may contain bugs, users rely on the behaviour that
> stable has. They may know about a bug but may have worked around it (and
> the update may break the workaround) or they do not know about a bug but a
> fix for it may break a previously functional system. And of course as we
> all know: bugfixes are not zero-risk and do have chances on new bugs being
> introduced.

Basically this argument is "the update may break things".

That's true, but the right questions are: how likely is that; how bad
are the bugs that would be fixed by the update; and so on.

> Being completely bug-free would be nice, but is probably unachievable. I
> think there's something to say for the predictability of a release: it may
> not be perfect, but once installed and tested it will keep working.

This argument seems very absolutist and would seem to suggest we
should never do any stable release updates at all.  But a user who
wants that level of stability can simply not take the stable release
updates, and only apply the security updates.

I think there is room for us relaxing our policy for stable updates.
Where upstream have a good track record of not breaking their own
stable branch, I think providing those updates to our users is
probably sensible.

Ian.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Philipp Kern | 1 Feb 2011 16:32
Picon

Re: Upstream "stable" branches and Debian freeze

On 2011-02-01, Ian Jackson <ijackson <at> chiark.greenend.org.uk> wrote:
> This argument seems very absolutist and would seem to suggest we
> should never do any stable release updates at all.  But a user who
> wants that level of stability can simply not take the stable release
> updates, and only apply the security updates.

That's not easily possible as stable as found on the mirrors is overriden
by point releases.[1]  So you'd need to mirror stable r0.

> I think there is room for us relaxing our policy for stable updates.
> Where upstream have a good track record of not breaking their own
> stable branch, I think providing those updates to our users is
> probably sensible.

First off they have to establish that track record with us, though.

(See also [2].  There will be a few updates to leaf packages in stable.
However updates to stable server software will be considered carefully,
and it depends on how we're convinced of the QA of maintainers and the
quality of upstream releases.  PostgreSQL did that[3].  For others we'll
act on a case-by-case basis.)

Kind regards
Philipp Kern

[1] Ubuntu does it a tad differently.  On normal releases their release suite
    isn't updated.  Instead updates are just pushed through the -updates suite.
    So here you're free to ignore those.  LTS do point releases like we do,
    though.
[2] http://lists.debian.org/debian-volatile-announce/2011/msg00000.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Timur Birsh | 1 Feb 2011 16:34
Favicon
Gravatar

Any Debian Developers traveling to Almaty? (GPG key sign needed)

Hello,

Are there any Debian Developers traveling to Almaty for the Asian Winter 
Games? I need a GPG key sign.

Thanks,
--

-- 
Timur
Permalink | Reply | 1 comment |
headers
Jesús M. Navarro | 1 Feb 2011 17:09

Re: Upstream "stable" branches and Debian freeze

Hi, Ian:

On Tuesday 01 February 2011 14:11:44 Ian Jackson wrote:
> Thijs Kinkhorst writes ("Re: Upstream "stable" branches and Debian freeze"):
> > In the past such things have not been allowed with the argumentation that
> > even though stable may contain bugs, users rely on the behaviour that
> > stable has. They may know about a bug but may have worked around it (and
> > the update may break the workaround) or they do not know about a bug but
> > a fix for it may break a previously functional system. And of course as
> > we all know: bugfixes are not zero-risk and do have chances on new bugs
> > being introduced.
>
> Basically this argument is "the update may break things".

[...]

> I think there is room for us relaxing our policy for stable updates.
> Where upstream have a good track record of not breaking their own
> stable branch, I think providing those updates to our users is
> probably sensible.

I don't think "relax" is the word but "reinterpret".

Why is the policy exactly the way it is?  It's obvious that changes are 
allowed as security and point releases show.  The "why" is obvious too: 
because security and/or severe malfunctions overweight the risk of breaking 
things *and* Debian release/security team try to minimize that risk by 
patching the bare minimum to achieve the intended result.

That said, I find that to be the proper way for a maintenance policy and an
(Continue reading)

Permalink | Reply | 2 comments |

Gmane