Wouter Verhelst writes ("Re: RFC: Policy 10.1 and appropriateness of package
conflicts"):
> wou...@celtic:~$ ls -l /usr/bin/gcc
> lrwxrwxrwx 1 root root 7 jun 6 07:23 /usr/bin/gcc -> gcc-4.4
> wou...@celtic:~$ dpkg -S /usr/bin/gcc
> gcc: /usr/bin/gcc
> wou...@celtic
On Sat, Aug 14, 2010 at 10:32:41AM +0900, Charles Plessy wrote:
>
> Also, the change of environment is not to make usable a program that would not
> be, but simply to make it the default choice or not, under its original
> upstream name, the one that our users expect, read in the documentation, he
On Sat, Aug 14, 2010 at 09:29:52AM -0700, Wouter Verhelst wrote:
> wou...@celtic:~$ ls -l /usr/bin/gcc
> lrwxrwxrwx 1 root root 7 jun 6 07:23 /usr/bin/gcc -> gcc-4.4
> wou...@celtic:~$ dpkg -S /usr/bin/gcc
> gcc: /usr/bin/gcc
> wou...@celtic:~$ dpkg -S /usr/bin/gcc-4.1
> gcc-4.1: /usr/bin/gcc-4.1
On Fri, Aug 13, 2010 at 03:38:39PM +0100, Ian Jackson wrote:
> So the only purpose of "fsl" is to provide these namespace-eating
> convenience symlinks ? If so I'm not sure that this is a good purpose
> for a a package.
wou...@celtic:~$ ls -l /usr/bin/gcc
lrwxrwxrwx 1 root root 7 jun 6 07:23 /us
On Fri, Aug 13, 2010 at 09:20:17AM -0400, Michael Hanke wrote:
> I'm trying to figure out a solution for RC bug #592242. The short
> summary of this bug is a package A that conflicts with a package B due
> to a name clash in /usr/bin. The programs in question do not provide the
> same functionality
Le Fri, Aug 13, 2010 at 05:22:51PM -0700, Russ Allbery a écrit :
>
> Please remember that setting the system-wide default PATH to support some
> applications installed on that system often makes no sense. Timeshare
> systems shared by many different people doing many different things are
> still
Charles Plessy writes:
> How about something among these lines:
> - A Blend provides a directory /usr/share/.
> - Packages can add symlinks there on a voluntary basis.
> - The blend installs a script in /etc/profile.d, that adds the
>symlinks directory to the PATH of the users that are
[ CC debian-blends: the problem is how to make sure that when a
program is renamed because of a file conflict with another program,
its users still have a chance to use it out of the box.]
Le Fri, Aug 13, 2010 at 01:44:04PM -0700, Russ Allbery a écrit :
> Ian Jackson writes:
>
> > I see. Co
Le vendredi 13 août 2010, Ian Jackson a écrit :
> I see. Couldn't you arrange to automatically update the default user
> PATH ? (After asking a suitable debconf question.) That would avoid
> having to Conflict with other packages and would make it possible for
> users of this fsl nonsense and us
Ian Jackson writes:
> I see. Couldn't you arrange to automatically update the default user
> PATH ? (After asking a suitable debconf question.) That would avoid
> having to Conflict with other packages and would make it possible for
> users of this fsl nonsense and users of different nonsense
Michael Hanke writes ("Re: RFC: Policy 10.1 and appropriateness of package
conflicts"):
> Well, it has been 'invented' to address a frequent user-problem that
> people can readily use the GUI parts of that package (because they are
> avialable via wrappers in /usr/b
On Fri, Aug 13, 2010 at 03:38:39PM +0100, Ian Jackson wrote:
> So the only purpose of "fsl" is to provide these namespace-eating
> convenience symlinks ? If so I'm not sure that this is a good purpose
> for a a package.
Well, it has been 'invented' to address a frequent user-problem that
people c
Andreas Tille writes ("Re: RFC: Policy 10.1 and appropriateness of package
conflicts"):
> On Fri, Aug 13, 2010 at 09:20:17AM -0400, Michael Hanke wrote:
> > However, the situation of #592242 is different. The package (fsl) that
> > conflicts with other packages (e.g
On Fri, Aug 13, 2010 at 09:20:17AM -0400, Michael Hanke wrote:
>
> Since renaming is not an option due to large side-effects in the
> packages in question,
In any case educating upstream about this name clash is very important
in cases like this. It's not only about Debian - the name clash might
14 matches
Mail list logo
