Bug#671507: debian-policy: policy section 7.4 conflicts with section 10.1

[Carsten Hey]

* Jonathan Nieder [2012-05-04 17:35 -0500]:
> Carsten Hey wrote:
> > * Patrick Ouellette [2012-05-04 13:38 -0400]:
>
> >> If you read the entire section 7.4 is seems entirely reasonable to
> >> create a package with an executable name that already exists in Debian
> >> with a package conflicts tag if the two executables have different
> >> functionality.
> >
> > But I want to play the boulder dash clone epiphany whilst browsing the
> > web using the epiphany browser!
>
> This misses the point.  The goal of policy §10.1 is that other
> packages (in Debian and elsewhere) can rely on a command name having a
> single, reliable meaning, independent of the $PATH setting and
> installed package set.

What you describe is one goal of §10.1's first paragraph, an other is
the one I hinted at, there is no reason to prohibit users to install two
unrelated programs that both use the same executable name upstream.

Due to support for partial upgrades, the situation that it is not clear
to a third package which program an executable name refers to (unless
package relation ship fields are used to circumvent this) is nothing new
in Debian and happend for example with epiphany.

Given that the affected maintainers are aware of it (for example they
know that "which command" would not lead to a useful result) and that
these situations are only temporary exceptions, then Debian is able to
handle such situations well as it did already in the past.

Carsten



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#671507: debian-policy: policy section 7.4 conflicts with section 10.1

[Jonathan Nieder]

Carsten Hey wrote:
> * Patrick Ouellette [2012-05-04 13:38 -0400]:

>> If you read the entire section 7.4 is seems entirely reasonable to
>> create a package with an executable name that already exists in Debian
>> with a package conflicts tag if the two executables have different
>> functionality.
>
> But I want to play the boulder dash clone epiphany whilst browsing the
> web using the epiphany browser!

This misses the point.  The goal of policy §10.1 is that other
packages (in Debian and elsewhere) can rely on a command name having a
single, reliable meaning, independent of the $PATH setting and
installed package set.

For example, it would be awfully strange if xdg-open or
sensible-browser caused the boulder dash clone epiphany to open.

If other packages use the "node" command to refer to Node.js, then the
Conflicts or Breaks being prevented would be by node against all of
those packages and by nodejs against packages that use "node" to refer
to LinuxNode.  



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#671507: debian-policy: policy section 7.4 conflicts with section 10.1

[Carsten Hey]

* Patrick Ouellette [2012-05-04 13:38 -0400]:
> "Conflicts should be used
>
> when two packages provide the same file and will continue to do so"

/usr/bin/sendmail is provided by citadel-mta, courier-mta, dma,
esmtp-run, exim4-daemon-heavy, exim4-daemon-light, ...

That is what the policy means by same file (but I agree that this
wording is a bit misleading), and not the same filename in a different
directory - otherwise all packages that provide a copyright file in
/usr/share/doc/*/ would have to conflict with each other.

> If you read the entire section 7.4 is seems entirely reasonable to
> create a package with an executable name that already exists in Debian
> with a package conflicts tag if the two executables have different
> functionality.

But I want to play the boulder dash clone epiphany whilst browsing the
web using the epiphany browser!

Carsten



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#671507: debian-policy: policy section 7.4 conflicts with section 10.1

[Patrick Ouellette]

On Fri, May 04, 2012 at 10:27:27AM -0700, Russ Allbery wrote:
> 
> Patrick Ouellette  writes:
> 
> > Policy 7.4 states 
> 
> > "Neither Breaks nor Conflicts should be used unless two packages cannot
> > be installed at the same time or installing them both causes one of them
> > to be broken or unusable. Having similar functionality or performing the
> > same tasks as another package is not sufficient reason to declare Breaks
> > or Conflicts with that package. "
> 
> > 7.4 suggests it is appropriate to conflict if a package installs an
> > executable with the same name as another package but different
> > functionality.
> 
> I'm not seeing where it suggests that personally, but I'm probably too
> close to it.  We can certainly add a pointer to 10.1 here.

Sorry, I should have copied this part of 7.4 too:

"Conflicts should be used

when two packages provide the same file and will continue to do so"

If you read the entire section 7.4 is seems entirely reasonable to
create a package with an executable name that already exists in Debian
with a package conflicts tag if the two executables have different 
functionality.

Section 10.1 says we can't ever do that.  10.1 also leaves open the
possibility of two executable with the same name in different packages
as long as the functionality is the same.  This might not be a good thing
if one package later adds/removes functionality.

Pat



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#671507: debian-policy: policy section 7.4 conflicts with section 10.1

[Russ Allbery]

Patrick Ouellette  writes:

> Policy 7.4 states 

> "Neither Breaks nor Conflicts should be used unless two packages cannot
> be installed at the same time or installing them both causes one of them
> to be broken or unusable. Having similar functionality or performing the
> same tasks as another package is not sufficient reason to declare Breaks
> or Conflicts with that package. "

> 7.4 suggests it is appropriate to conflict if a package installs an
> executable with the same name as another package but different
> functionality.

I'm not seeing where it suggests that personally, but I'm probably too
close to it.  We can certainly add a pointer to 10.1 here.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#671507: debian-policy: policy section 7.4 conflicts with section 10.1

[Patrick Ouellette]

Package: debian-policy
Severity: normal

Policy 7.4 states 
"Neither Breaks nor Conflicts should be used unless two packages cannot be 
installed at the same time or installing them both causes one of them to be 
broken or unusable. Having similar functionality or performing the same tasks 
as another package is not sufficient reason to declare Breaks or Conflicts with 
that package. "

Policy 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."

7.4 suggests it is appropriate to conflict if a package installs an executable
with the same name as another package but different functionality.

10.1 states two packages can not have executables with the same name - ever

please fix the discrepancy


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.1.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org