On 2018-09-08, Sylvestre Ledru wrote:
>> Two different packages must not install programs with different
>> functionality but with the same filenames.
>>
> I think the policy should be changed.
> It was possible to accommodate that when the archive was a few thousand
> packages.
> Or am
Russ Allbery wrote on 09/09/2018:
> Paride Legovini writes:
>
>> However, there are clearly cases where renaming binaries makes several
>> people unhappy (most likely: the package maintainers, upstream, people
>> writing scripts, users of different distributions), while not making a
>> single use
On Sep 08, Sean Whitton wrote:
> The current policy protects maintainers and users of less popular
> packages from feeling that their package is less important in Debian,
> just because something else that is more popular comes along and happens
> to use the same name.
Yes, and the I do not think
On Sat, Sep 08, 2018 at 08:18:10PM +0200, Sylvestre Ledru wrote:
For example, in the Rust team, we have been discussing about packaging fd (a
find alternative developed using rust [1]).
We are planning to install it in /usr/bin/fd .. but this conflicts with
something completely different, fdclo
Paride Legovini writes:
> It would certainly work, but as you say it is still irritating. I like
> the idea of putting the binaries in a different directory *and*
> providing a "name compatibility package", as it has been already
> suggested. This package would provide the symlinks in /usr/bin an
Russ Allbery wrote on 09/09/2018:
> Oh, hm, yes, I rather like this idea too, particularly combined with
> putting those symlink packages in their own namespace (and maybe their > own
> section).
Totally makes sense.
> Maybe this is overkill for the relatively small number of these packages
> we
Sean Whitton writes ("Re: Updating the policy for conflicting binaries names ?
[was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already
taken]"):
> The current policy means that the discussion about which package should
> use the name begins on neutral ground, without prejudice
Paride Legovini writes ("Re: Updating the policy for conflicting binaries names
? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already
taken]"):
> It would certainly work, but as you say it is still irritating. I like
> the idea of putting the binaries in a different directo
Marco d'Itri writes ("Re: Updating the policy for conflicting binaries names ?
[was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already
taken]"):
> On Sep 08, Sean Whitton wrote:
> > The current policy protects maintainers and users of less popular
> > packages from feeling tha
❦ 9 septembre 2018 21:53 +0100, Ian Jackson :
>> The current policy maximizes discomfort for all parts involved in the
>> name of creating equality where it does not actually exist, and this
>> does not help anybody.
>
> I think it did create equality in that the inconvenience for each
> maint
On Sun, 9 Sep 2018 at 04:52, Sean Whitton wrote:
> Hello,
>
> On Sat 08 Sep 2018 at 10:02AM +0800, Paul Wise wrote:
>
> > On Fri, Sep 7, 2018 at 7:22 PM, Bastien ROUCARIES wrote:
> >
> >> Ok adding cc @security
> >>
> >> How will you handle security problem in static
> >> (browserified/webpacked)
Hello,
On Mon 10 Sep 2018 at 11:00AM +1200, Michael Hudson-Doyle wrote:
> I actually implemented something like this for Go in Ubuntu when we were
> looking at building Go shared libraries but we gave up on that whole
> approach (because even minor releases of Go upstream tend to break ABI and
>
On September 9, 2018 9:36:01 PM UTC, Vincent Bernat wrote:
>❦ 9 septembre 2018 21:53 +0100, Ian Jackson
>:
>
>>> The current policy maximizes discomfort for all parts involved in
>the
>>> name of creating equality where it does not actually exist, and this
>
>>> does not help anybody.
>>
>> I
Hi,
Merge-request for developers-reference is now available:
https://salsa.debian.org/debian/developers-reference/merge_requests/5
Kudos to all who helped me making this possible!
--
tobi
signature.asc
Description: PGP signature
14 matches
Mail list logo
