Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Colin Watson]

On Mon, Oct 08, 2018 at 01:14:10PM +0100, Ian Jackson wrote:
> Steffen Möller writes ("Re: Updating the policy for conflicting binaries 
> names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - 
> already taken]"):
> > If someone
> > happens to be in two such communities then Debian makes it easy enough
> > for everyone to just install a package quickly when this is needed and
> > to then deinstall it when that tool's execution's purpose is done.
> 
> So if I want package X on a porterbox, and another Debian porter wants
> package Y, and they conflict because of poorly chosen command names,
> the two of us should coordinate so that we can send a suitable series
> of each-other-reverting updates to the DSA ansible repo and thereby
> arrange to both do our work, albeit interleaved rather than
> simultaneously ?

I don't disagree with you in general, but this is a bad example since
the way you work on porterboxes these days is to run a thing that gives
you your own schroot instance (https://dsa.debian.org/doc/schroot).

-- 
Colin Watson   [cjwat...@debian.org]

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Ian Jackson]

Steffen Möller writes ("Re: Updating the policy for conflicting binaries names 
? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already 
taken]"):
> If someone
> happens to be in two such communities then Debian makes it easy enough
> for everyone to just install a package quickly when this is needed and
> to then deinstall it when that tool's execution's purpose is done.

So if I want package X on a porterbox, and another Debian porter wants
package Y, and they conflict because of poorly chosen command names,
the two of us should coordinate so that we can send a suitable series
of each-other-reverting updates to the DSA ansible repo and thereby
arrange to both do our work, albeit interleaved rather than
simultaneously ?

Ian.

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Steffen Möller]

Hello,

On 09.09.18 02:11, Russ Allbery wrote:
> 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 user happier. This is especially true with low popcon packages
>> with a small use case intersection.
> If the packages conflict, though, this is extremely unfriendly to the
> users who do want to use both packages.  They cannot use both packages on
> the same OS installation, and have to resort to chroots or VMs or
> containers, which is a lot of extra complexity.  I'm therefore in favor of
> keeping Policy's prohibition on using Conflicts for this case; maybe a
> combination of two packages will get lucky and there will be literally no
> users who want to use both at the same time, but it's very hard to tell
> when that's the case and the failure mode is ugly.
>
> I kind of like the solution of putting the binaries in a different
> directory.  This is also a little irritating, since users have to add an
> additional directory to their PATH, but they only have to do that once and
> it works consistently going forward, and they can still use the other
> program.
>
> It's not totally unheard of to have to modify PATH to use a package,
> particularly one that wants to use a bunch of very generic command names.
> That was always the official way to use MH, for example.

You may be referring to some alike http://modules.sourceforge.net/   And
yes, I personally would not mind if Debian packages would have an option
to install into such a module. Actually, this would even help a lot for
the parallel installation of multiple versions of the same
library/binary, which is not uncommon in scientific workflows (sadly).

It seems like I am a bit in a minority position here. And it hurts me to
contradict all those folks who one respects for all the good work they
do. Anyway, in my very humble and personal opinion, the policy of not
having conflicts makes perfect sense for anything that is essential to
have. But for anything optional, well, that conflict is optional, too.
We should allow ourselves to rely more on upstream's communities to take
care not to conflict with names. That is because they talk with each
other and most likely they have an idea what they talk about. If someone
happens to be in two such communities then Debian makes it easy enough
for everyone to just install a package quickly when this is needed and
to then deinstall it when that tool's execution's purpose is done. I
mean, this is why we are doing this all after all. We should take some
pride in what we achieved and tell people to use our package managers
when conflicts arise as a dear exception. Conflicts are natural. We
should find a way to deal with them and not come up with a dysfunctional
world of compromises that annoys by default and not just as a
theoretical construct. Also, I think we can rest assured, if communities
have not talked and named binaries the same, then the conflicts between
the respective packages is what will help to persuade those communities
to adjust their naming.

Cheers,

Steffen

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Philip Hands]

Philip Hands  writes:

> Paride Legovini  writes:
>
>> Adam Borowski wrote on 14/09/2018:
>>> On Thu, Sep 13, 2018 at 11:28:36PM +0200, Thomas Goirand 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, fdclone a clone of fd, a MS-DOS file browser...

 fdclone isn't a shell utility, you just start it once, then you use its
 ncurse-like interface. Renaming it /usr/bin/fdclone wouldn't be a
 problem at all
>>> 
>>> It _already_ is a symlink pair between "fd" and "fdsh".  For the executable,
>>> "fd" is the master, "fdsh" the slave, the man page prefers "fdsh".
>>
>> I am the prospect maintainer of fd-find; thanks for spotting this. I
>> will ask the current maintainer of fdclone if he's willing to drop the
>> 'fd' binary, keeping only 'fdsh' (upstream installs both as hard links).
>> Shouldn't this be possible, I'll install the fd-find binary and man as:
>>
>> /usr/share/fd-find/bin/fd
>> /usr/share/fd-find/man/man1/fd.1.gz
>>
>> and provide the convenience symlinks:
>>
>> /usr/bin/fdfind -> /usr/share/fd-find/bin/fd
>> /usr/share/man/man1/fdfind.1.gz -> /usr/share/fd-find/man/man1/fd.1.gz
>>
>> Does this sound reasonable?
>
> It strikes me as rather presumptious to be trying to grab a new two
> letter command at this point in the history of *nix (particularly when
> it is already in use).
>
> Personally, I'll never willingly install a binary named that, because it
> seems very likely to tickle my dyslexia.  I'd expect it to make me very
> grumpy if I ever have to maintain a script that includes references to
> both df and fd nearby one another.

Ignore the above -- I managed to misread what you asked as dropping 'fd'
into /usr/bin, which is the oposite of what you were actually asking.

Sorry if I introduced any aditional confusion.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Sean Whitton]

Hello,

On Fri 14 Sep 2018 at 07:13PM +0200, Paride Legovini wrote:

> and provide the convenience symlinks:
>
> /usr/bin/fdfind -> /usr/share/fd-find/bin/fd
> /usr/share/man/man1/fdfind.1.gz -> /usr/share/fd-find/man/man1/fd.1.gz
>
> Does this sound reasonable?

Assuming this is a arch-dependent binary (since it's written in rust),
/usr/lib rather than /usr/share.  And ISTM it should be /usr/lib/fdfind
not /usr/lib/fd-find but maybe I'm missing something.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Philip Hands]

Paride Legovini  writes:

> Adam Borowski wrote on 14/09/2018:
>> On Thu, Sep 13, 2018 at 11:28:36PM +0200, Thomas Goirand 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, fdclone a clone of fd, a MS-DOS file browser...
>>>
>>> fdclone isn't a shell utility, you just start it once, then you use its
>>> ncurse-like interface. Renaming it /usr/bin/fdclone wouldn't be a
>>> problem at all
>> 
>> It _already_ is a symlink pair between "fd" and "fdsh".  For the executable,
>> "fd" is the master, "fdsh" the slave, the man page prefers "fdsh".
>
> I am the prospect maintainer of fd-find; thanks for spotting this. I
> will ask the current maintainer of fdclone if he's willing to drop the
> 'fd' binary, keeping only 'fdsh' (upstream installs both as hard links).
> Shouldn't this be possible, I'll install the fd-find binary and man as:
>
> /usr/share/fd-find/bin/fd
> /usr/share/fd-find/man/man1/fd.1.gz
>
> and provide the convenience symlinks:
>
> /usr/bin/fdfind -> /usr/share/fd-find/bin/fd
> /usr/share/man/man1/fdfind.1.gz -> /usr/share/fd-find/man/man1/fd.1.gz
>
> Does this sound reasonable?

It strikes me as rather presumptious to be trying to grab a new two
letter command at this point in the history of *nix (particularly when
it is already in use).

Personally, I'll never willingly install a binary named that, because it
seems very likely to tickle my dyslexia.  I'd expect it to make me very
grumpy if I ever have to maintain a script that includes references to
both df and fd nearby one another.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Paride Legovini]

Adam Borowski wrote on 14/09/2018:
> On Thu, Sep 13, 2018 at 11:28:36PM +0200, Thomas Goirand 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, fdclone a clone of fd, a MS-DOS file browser...
>>
>> fdclone isn't a shell utility, you just start it once, then you use its
>> ncurse-like interface. Renaming it /usr/bin/fdclone wouldn't be a
>> problem at all
> 
> It _already_ is a symlink pair between "fd" and "fdsh".  For the executable,
> "fd" is the master, "fdsh" the slave, the man page prefers "fdsh".

I am the prospect maintainer of fd-find; thanks for spotting this. I
will ask the current maintainer of fdclone if he's willing to drop the
'fd' binary, keeping only 'fdsh' (upstream installs both as hard links).
Shouldn't this be possible, I'll install the fd-find binary and man as:

/usr/share/fd-find/bin/fd
/usr/share/fd-find/man/man1/fd.1.gz

and provide the convenience symlinks:

/usr/bin/fdfind -> /usr/share/fd-find/bin/fd
/usr/share/man/man1/fdfind.1.gz -> /usr/share/fd-find/man/man1/fd.1.gz

Does this sound reasonable?

Paride

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Ben Finney]

Ian Jackson  writes:

> Adrian Bunk writes:
> > I thought this would would have been less offensive than the normal
> > "This is a lie."
>
> You should never accuse someone of lying unless you are sure that they
> know that what they are saying is wrong.

For Adrian (since you acknowledged non-native English language status):
Ian is pointing out the distinction between “That is a lie” (asserting
the person knowingly intended to communicate a falsehood), versus
alternatives like “That is false” or “That is not true” (which carries
no implication of the person's intention or state of mind).

> If you can prove that someone is deliberately saying untrue things on
> Debian lists, that is abuse which should be reported and stopped.

If you don't want to support a claim that someone is lying, you can
avoid that implication: Just point out that the statement is not true
(and then do as you (Adrian) did to show how you know it's not true).

I hope that helps!

-- 
 \“Considering the current sad state of our computer programs, |
  `\ software development is clearly still a black art, and cannot |
_o__)  yet be called an engineering discipline.” —Bill Clinton |
Ben Finney

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Adam Borowski]

On Thu, Sep 13, 2018 at 11:28:36PM +0200, Thomas Goirand 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, fdclone a clone of fd, a MS-DOS file browser...
> 
> fdclone isn't a shell utility, you just start it once, then you use its
> ncurse-like interface. Renaming it /usr/bin/fdclone wouldn't be a
> problem at all

It _already_ is a symlink pair between "fd" and "fdsh".  For the executable,
"fd" is the master, "fdsh" the slave, the man page prefers "fdsh".


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Thomas Goirand]

On 09/08/2018 08:18 PM, Sylvestre Ledru wrote:
> Hello,
> 
> Le 08/09/2018 à 18:39, Sean Whitton a écrit :
>> Hello,
>>
>> On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote:
>>
>>> However, I think the policy gives us a lot of freedom to choose (it is not 
>>> very
>>> strict in this case).
>>
>> I don't understand.  This seems pretty strict:
>>
>> 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.
> Now that it is much bigger, that floss are everywhere, packages are being 
> forked,
> we might want to update the policy to give more flexibility.

If by more flexibility, you mean allowing packages to conflict, I'm all
against it. I would loose trust in Debian.

By the way, forks aren't a problem, it means both packages provides the
same functionality.

> 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, fdclone a clone
> of fd, a MS-DOS file browser...

fdclone isn't a shell utility, you just start it once, then you use its
ncurse-like interface. Renaming it /usr/bin/fdclone wouldn't be a
problem at all, and would be useful if you need to use /usr/bin/fd,
which may be useful in shell scripts (which means you need a specific
name so that examples one may find online can work in Debian).

> Renaming binaries is a big pain, it is confusing for the user, making the 
> life of the maintainer
> harder, the documentations won't reflect the Debian-reality.

I really prefer this over allowing file collisions.

Cheers,

Thomas Goirand (zigo)

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Sean Whitton]

Hello,

On Wed 12 Sep 2018 at 06:19PM +0200, Ruben Undheim wrote:

> I guess the "long description" for the package can also refer to README.Debian
> for how to handle the "issue", to make the user aware of it even before
> installing it.

This seems fine, though it would be nice if it wasn't needed, i.e., if
the presence of a README.Debian in a package was flagged to the user as
package metadata.  Such that the presence of the file is enough, rather
than having to add the file and a note in the package description.  But
we don't have that yet.  Just a thought.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Adam D. Barratt]

On Wed, 2018-09-12 at 22:34 +0300, Adrian Bunk wrote:
> 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, fdclone a clone
> > of fd, a MS-DOS file browser...
> > While this is probably fun, with a declining popcon (104 today),
> > and no upstream release since 2013,
> 
> This is fake news.
> 
> The latest upstream release was one month ago.

Leaving aside the issues with wording, as I think others have covered
that sufficiently already, Sylvestre's was a relatively simple mistake
to make.

Googling for "fdclone" leads one to https://github.com/knu/FDclone as
the first hit (at least it does for me), which indeed says "Latest
commit 460e591 on 7 Jun 2013".

Regards,

Adam

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Russ Allbery]

Adrian Bunk  writes:

> I thought this would would have been less offensive than the normal
> "This is a lie." when a statement is the exact opposite of the
> truth (compare [1] with the claim "no upstream release since 2013"), 
> but as non-native speaker I accept your explanation that I was wrong
> on that.

"I don't think this is correct" is a less confrontational way of phrasing
this that assumes the other person is writing in good faith and just made
a mistake, as opposed to maliciously attempted to deceive people, which is
what both your original phrasing and "this is a lie" (unintentionally, I
assume) implied.

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Nicholas D Steeves]

On Thu, Sep 13, 2018 at 12:31:40AM +0300, Adrian Bunk wrote:
> On Wed, Sep 12, 2018 at 09:18:13PM +0100, Chris Lamb wrote:
> > Dear Adrian,
> 
> Dear Chris,
> 
> > > This is fake news.
> > 
> > Please try and avoid casual use of this term on Debian lists.
> > 
> > Whilst I understand your meaning and intentions, the term has now been
> > so overused and overapplied and has been evacuated of all useful
> > meaning.
> > 
> > Indeed, its use now appears to only distract & unnecessarily antagonise
> > readers and should probably be considered an illegal move in civilised
> > or otherwise productive conversation.
> 
> I thought this would would have been less offensive than the normal
> "This is a lie." when a statement is the exact opposite of the
> truth (compare [1] with the claim "no upstream release since 2013"), 
> but as non-native speaker I accept your explanation that I was wrong
> on that.

I agree, no one likes being called a liar, but "This is untrue", "this
is false", and "this is a falsehood" are more neutral than "this is a
lie", because a lie is the product of lying, and lying includes the
intent to deceive and/or mislead.  Better to allow for the possibility
that someone was mistaken or misspoke ;-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Ian Jackson]

Adrian Bunk writes ("Re: Updating the policy for conflicting binaries names ? 
[was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already 
taken]"):
> I thought this would would have been less offensive than the normal
> "This is a lie."

You should never accuse someone of lying unless you are sure that they
know that what they are saying is wrong.

If you can prove that someone is deliberately saying untrue things on
Debian lists, that is abuse which should be reported and stopped.
Report such things to listmaster.

I can see no useful purpose being served by publicly claiming that
some other participant here is lying.

Ian.

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Ian Jackson]

Ruben Undheim writes ("Re: New package netgen-lvs with binary /usr/bin/netgen - 
already taken"):
> Actually just putting a note in README.Debian saying something like this...
> 
>   If you would like to use netgen-lvs with the upstream name "netgen",
>   set the PATH environment variable to  PATH=/usr/lib/netgen-lvs/bin:$PATH
> 
>   To permanently enable the upstream binary name "netgen" for a user, you can
>   for example add the following to the shell startup source file (~/.bashrc,
>   ~/.zshrc ..):
> 
> export PATH=/usr/lib/netgen-lvs/bin:$PATH

You might want to consider writing something to discourage this
approach.  It is superficially easy, but it can cause trouble if the
same user later wants the other netgen too.

Ian.

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Sylvestre Ledru]

Le 12/09/2018 à 23:31, Adrian Bunk a écrit :
> On Wed, Sep 12, 2018 at 09:18:13PM +0100, Chris Lamb wrote:
>> Dear Adrian,
> Dear Chris,
>
>>> This is fake news.
>> Please try and avoid casual use of this term on Debian lists.
>>
>> Whilst I understand your meaning and intentions, the term has now been
>> so overused and overapplied and has been evacuated of all useful
>> meaning.
>>
>> Indeed, its use now appears to only distract & unnecessarily antagonise
>> readers and should probably be considered an illegal move in civilised
>> or otherwise productive conversation.
> I thought this would would have been less offensive than the normal
> "This is a lie." when a statement is the exact opposite of the
> truth (compare [1] with the claim "no upstream release since 2013"), 
> but as non-native speaker I accept your explanation that I was wrong
> on that.
>
It was just a mistake in my side. I was confused by the letters in the
version
and the absence of uploads in 2015, 2016 & 2017.

By the way, thanks Chris!

Sylvestre

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Adrian Bunk]

On Wed, Sep 12, 2018 at 09:18:13PM +0100, Chris Lamb wrote:
> Dear Adrian,

Dear Chris,

> > This is fake news.
> 
> Please try and avoid casual use of this term on Debian lists.
> 
> Whilst I understand your meaning and intentions, the term has now been
> so overused and overapplied and has been evacuated of all useful
> meaning.
> 
> Indeed, its use now appears to only distract & unnecessarily antagonise
> readers and should probably be considered an illegal move in civilised
> or otherwise productive conversation.

I thought this would would have been less offensive than the normal
"This is a lie." when a statement is the exact opposite of the
truth (compare [1] with the claim "no upstream release since 2013"), 
but as non-native speaker I accept your explanation that I was wrong
on that.

> Best wishes,

cu
Adrian

[1] ftp://ftp.unixusers.net/src/fdclone/

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Chris Lamb]

Dear Adrian,

> This is fake news.

Please try and avoid casual use of this term on Debian lists.

Whilst I understand your meaning and intentions, the term has now been
so overused and overapplied and has been evacuated of all useful
meaning.

Indeed, its use now appears to only distract & unnecessarily antagonise
readers and should probably be considered an illegal move in civilised
or otherwise productive conversation.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Adrian Bunk]

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, fdclone a clone
> of fd, a MS-DOS file browser...
> While this is probably fun, with a declining popcon (104 today), and no 
> upstream release since 2013,

This is fake news.

The latest upstream release was one month ago.

The software is developed and used since 1995.

What will be the development status and usage of the Rust "fd"
in the year 2040?

Or today?
At first sight "find program with different syntax" sounds like some 
package people will want to remove from Debian as obsolete cruft in
a few years.

"bat" from the same author also reminds me of "dog"[1].

> I am not sure it is relevant to reverse the path for a leaf packages like 
> this one.
>...

For git, node and chromium there were real problems since widely used 
programs took names that were previously used by fringe packages.

One guy on GitHub giving his fringe programs names like "bat" or "fd",
the sane solutions are to either rename or not package.

Making it easy for fringe programs to take over already used names
would cause more trouble that it would be worth.

> Cheers,
> Sylvestre
>...

cu
Adrian

[1] https://tracker.debian.org/pkg/dog

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Ruben Undheim]

Hi,


After now having seen many arguments (this thread became longer than
anticipated) for both changing the policy and for keeping it the way it is, I
am now quite convinced that the policy should be the way it is!

> > stupid idea:
> > 
> > do these scripts (and other consumers of the netgen binaries) actually
> > use the fully qualified "/usr/bin/netgen" or just an unqualified "netgen"?
> > 
> > if the latter, you might just put the unchanged names into something
> > like /usr/share/netgen/bin/ and tell users to add to that to their PATH
> > when running their scripts.
> > that provides a simple compat layer for out-of-distro scripts.
> > rdeps in Debian should be patched to use debianized script-names.

For netgen-lvs, I will just put the binary using the upstream name in
  /usr/lib/netgen-lvs/bin
There will be a symlink in /usr/bin/netgen-lvs pointing to
/usr/lib/netgen-lvs/bin/netgen


Actually just putting a note in README.Debian saying something like this...

  If you would like to use netgen-lvs with the upstream name "netgen",
  set the PATH environment variable to  PATH=/usr/lib/netgen-lvs/bin:$PATH

  To permanently enable the upstream binary name "netgen" for a user, you can
  for example add the following to the shell startup source file (~/.bashrc,
  ~/.zshrc ..):

export PATH=/usr/lib/netgen-lvs/bin:$PATH

  ...


should solve the problem.

This way, we do not globally mess up the namespace for the system. It will
only apply for specific users (root is not affected if not explicitly touched,
and hence not system scripts).

It makes it easy to see exceptions (echo $PATH), and we do not have to waste
time making "ugly" compatibility packages.

At the same time, the user will be encouraged to use the Debian name for the
executable if possible.


I guess the "long description" for the package can also refer to README.Debian
for how to handle the "issue", to make the user aware of it even before
installing it.


This may even be good enough for more complicated cases such as nodejs (was)?

Thanks IOhannes for the suggestion..


Best regards,
Ruben

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Stuart Prescott]

Jonathan Dowland wrote:

> Yes. Is "environment-modules" well-known these days? I'm surprised not
> to see it mentioned more often.

Indeed, environment-modules and direnv and excellent tools for this sort of 
game.

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Jonas Smedegaard]

Quoting Jonathan Dowland (2018-09-11 15:27:00)
> On Sun, Sep 09, 2018 at 11:36:01PM +0200, Vincent Bernat wrote:
> >There were no users of the ax25's node binary (and almost no users 
> >for the package, as demonstrated later). The inconvenience was 
> >shifted entirely on the users of the nodejs package. Our motto is to 
> >care about our users, not to inconvenience them for the sake of 
> >non-existing users.
> 
> How popular is the nodejs binary amongst node(.js) users? The advice I 
> see from the Node community (and the Rust community and the Go 
> community and…) is to completely ignore the distro packaging and use 
> upstream directly.

I don't have numbers, but noticed that it was popular enough for guides 
to emerge instructing to install the nodejs.legacy package - which was 
needed _only_ when users need /usr/bin/node (until later simplified).

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Jonathan Dowland]

On Sat, Sep 08, 2018 at 05:11:23PM -0700, Russ Allbery wrote:

I kind of like the solution of putting the binaries in a different
directory.  This is also a little irritating, since users have to add an
additional directory to their PATH, but they only have to do that once and
it works consistently going forward, and they can still use the other
program.

It's not totally unheard of to have to modify PATH to use a package,
particularly one that wants to use a bunch of very generic command names.
That was always the official way to use MH, for example.


Yes. Is "environment-modules" well-known these days? I'm surprised not
to see it mentioned more often.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Julien Cristau]

On 09/09/2018 03:46 AM, Guillem Jover wrote:
> Hi!
> 
> On Sat, 2018-09-08 at 20:18:10 +0200, Sylvestre Ledru wrote:
>> Le 08/09/2018 à 18:39, Sean Whitton a écrit :
>>> On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote:
 However, I think the policy gives us a lot of freedom to choose (it
 is not very strict in this case).
>>>
>>> I don't understand.  This seems pretty strict:
>>>
>>> Two different packages must not install programs with different
>>> functionality but with the same filenames.
> 
>> I think the policy should be changed.
> 
> I'd very very strongly oppose any such change.
> 
Ditto.

Cheers,
Julien

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Jonathan Dowland]

On Sun, Sep 09, 2018 at 11:36:01PM +0200, Vincent Bernat wrote:

There were no users of the ax25's node binary (and almost no users for
the package, as demonstrated later). The inconvenience was shifted
entirely on the users of the nodejs package. Our motto is to care about
our users, not to inconvenience them for the sake of non-existing users.


How popular is the nodejs binary amongst node(.js) users? The advice I
see from the Node community (and the Rust community and the Go community
and…) is to completely ignore the distro packaging and use upstream
directly.

It seems the practical use of these interpreters/package managers/etc
seems to be in fulfilling dependencies of other, user-facing tools,
rather than to be used directly. And under that lens, local binary
renaming or putting them outside /usr/bin etc is less disruptive
(because the interface to that is encoded in the packaging of the
dependents).


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Peter Pentchev]

On Sun, Sep 09, 2018 at 09:32:36PM +0100, Ian Jackson wrote:
> 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 directory *and*
> > providing a "name compatibility package", as it has been already
> > suggested. This package would provide the symlinks in /usr/bin and set
> > the needed Conflicts. In this way we allow both packages to be installed
> > at the same time while leaving the users enough freedom to chose what to
> > have in their PATH.
> 
> This is not a bad idea but we should impose some serious restrictions:
> 
>  * The basic principle is that the compat name, and the compat
>package, is provided for users and nothing in Debian (even the
>package itself) may use it.
> 
>  * Other packages MUST NOT depend on or recommend the -debcompat
>package.  The reasons for this should be obvious.
> 
>  * No program (including parts of the same package) should run the
>program by the compat name (by setting PATH, for exmaple).
> 
>This is because PATH settings leak: modern software often calls
>other programs, and even if it doesn't do so now it may do so in
>future.

Even this runs the risk of a user thinking "OK, so now I have a choice
between rewriting existing scripts and installing the -debcompat package;
come on, rewrite scripts, really?!" and getting into the habit of
installing the -debcompat package, putting that into all kinds of
automated installations and local (DarkPAN-style) packages and install
scripts, etc...  and then, months down the road, somebody else wants to
install the other package and it's much more work to rewrite all the scripts
*then*, when they should have been rewritten earlier.

Just a datapoint; I personally do not have any kind of stake in this.

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Scott Kitterman]

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 think it did create equality in that the inconvenience for each
>> maintainer/user of the offending packages was similar.
>
>There were no users of the ax25's node binary (and almost no users for
>the package, as demonstrated later). The inconvenience was shifted
>entirely on the users of the nodejs package. Our motto is to care about
>our users, not to inconvenience them for the sake of non-existing
>users.

That's not the typical case the policy serves.  If you don't like the nodejs 
decision, pick one or more of the TC or nodejs upstream to be annoyed with.  TC 
could have done whatever they wanted in that case.

Personally, I've been involved in one of these cases that only affected two 
minor leaf packages and the maintainers worked it out.  The "or both have to 
rename" part of the policy was a good motivation to try and work something out.

Scott K

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Vincent Bernat]

 ❦  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
> maintainer/user of the offending packages was similar.

There were no users of the ax25's node binary (and almost no users for
the package, as demonstrated later). The inconvenience was shifted
entirely on the users of the nodejs package. Our motto is to care about
our users, not to inconvenience them for the sake of non-existing users.
-- 
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"


signature.asc
Description: PGP signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Ian Jackson]

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 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 that this is a good idea as we have seen 
> with the nodejs fiasco.
> It is a fact of life that some packages are more popular ("important") 
> than others, and pretending that this is not true does not change it.

I think the way we handled node.js was correct.

It is true that many people were inconvenienced.  But most of those
who were inconvenienced who you are saying shouldn't have been, were
the people who chose the pckage which (i) came late (ii) whose
upstreams were totally inconsiderate.

It is right to impose the costs of an unjust act on those who are
aligned with the perpetrators, and not on the victims.

> 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
maintainer/user of the offending packages was similar.

Ian.

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Ian Jackson]

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 directory *and*
> providing a "name compatibility package", as it has been already
> suggested. This package would provide the symlinks in /usr/bin and set
> the needed Conflicts. In this way we allow both packages to be installed
> at the same time while leaving the users enough freedom to chose what to
> have in their PATH.

This is not a bad idea but we should impose some serious restrictions:

 * The basic principle is that the compat name, and the compat
   package, is provided for users and nothing in Debian (even the
   package itself) may use it.

 * Other packages MUST NOT depend on or recommend the -debcompat
   package.  The reasons for this should be obvious.

 * No program (including parts of the same package) should run the
   program by the compat name (by setting PATH, for exmaple).

   This is because PATH settings leak: modern software often calls
   other programs, and even if it doesn't do so now it may do so in
   future.

> As we want the packages to be discoverable, I would name them something
> like this:
> 
> -debcompat (for "compatible with the other Debian packages"):
> installs binaries in /usr/share//bin, does not set Conflicts,
> warns the user in the Description, Suggests .
> 
> : installs the /usr/bin symlinks, sets the required Conflicts,
> depends on -compat.

I think this is backwards.  Also it will result in violations of the
rules I state above.

> A "first come best served, modulo a different debian-devel consensus,
> modulo CTTE" policy could be good enough to decide which package
> deserves to install the "real" binary in /usr/bin.

I am in favour of my "cut the child in half" rule, as a general rule.

> We have to recognize that there is no perfect solution here. If we
> enforce the rename it will often be a big hassle for several people for
> a little gain while still leaving room for ambiguity (e.g. user set-up
> aliases and symlinks). On the other side if we allow Conflicts to be
> always used we will end up having useful but incompatible packages. I
> think the best compromise is somewhere in between.

Convenience for the amjority needs to be tempered with justice, and
consideration for the future.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Ian Jackson]

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 against the
> less popular package.  By requiring that they both change their names if
> agreement cannot be reached, the maintainers put on equal footing.

In addition to what Sean wrote:

The current policy means that if for some reason one wants to install
and use both programs in the same system, that is possible.  (Of course
this will be relevant if anyone ever wants to do something that
involves _both_ programs, and nowadays it is hard to rule out in
advance any interesting combinations.)

It also provides a (fairly weak, but nonneglible) incentive for
program authors not to engage in namespace landgrabs.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Paride Legovini]

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 run into, but it provides some basis for writing more interesting
> tools.
In my not-so-long life as a Debian package maintainer I encountered the
issue several times, specifically with:

 * [ITP] fd-find: https://github.com/sharkdp/fd
   (/usr/bin/fd clashes with package fdclone)

 * [ITP] bat: https://github.com/sharkdp/bat
   (/usr/bin/bat clashes with bareos-bat)

 * imv: /usr/bin clashes with renameutils.
   I renamed the binary and manpage to 'imvr'

 * [dropped ITP] spm: https://notabug.org/kl3/spm
   /usr/bin/spm clashes with salt-common
   I ended up dropping the ITP for spm for several reasons.

Sure the number of packages with a binary file clash problem is
relatively small, but I don't think the issue can be ignored.

Paride

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Russ Allbery]

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 and set
> the needed Conflicts. In this way we allow both packages to be installed
> at the same time while leaving the users enough freedom to chose what to
> have in their PATH.

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).

Maybe this is overkill for the relatively small number of these packages
we run into, but it provides some basis for writing more interesting
tools.  For example, if we could standardize an alternatives-style way of
selecting between various packages providing the same binary names, we
could provide user tools that would let individual users select which one
to prefer by updating their own PATH.

I agree that we're likely to see more of this problem as the overall
universe of software available and has been packaged continues to expand,
and not all of the problems have relatively easy solutions.

(Node, which came up elsewhere in this thread, was a particularly
challenging problem because it was an interpreter and had to be referenced
in #! lines.  Hopefully we won't have that specific problem frequently.)

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Michael Stone]

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, fdclone a clone
of fd, a MS-DOS file browser...


I think it's fairly idiotic to try to claim "fd" as a binary name in 
2018. 


Mike Stone

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Marco d'Itri]

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 that this is a good idea as we have seen 
with the nodejs fiasco.
It is a fact of life that some packages are more popular ("important") 
than others, and pretending that this is not true does not change it.

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.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Paride Legovini]

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 user happier. This is especially true with low popcon packages
>> with a small use case intersection.
> 
> If the packages conflict, though, this is extremely unfriendly to the
> users who do want to use both packages.  They cannot use both packages on
> the same OS installation, and have to resort to chroots or VMs or
> containers, which is a lot of extra complexity.  I'm therefore in favor of
> keeping Policy's prohibition on using Conflicts for this case; maybe a
> combination of two packages will get lucky and there will be literally no
> users who want to use both at the same time, but it's very hard to tell
> when that's the case and the failure mode is ugly.

I agree, and in fact I don't suggest Conflicts right away (though I
think it can be the best solution in some cases).

> I kind of like the solution of putting the binaries in a different
> directory.  This is also a little irritating, since users have to add an
> additional directory to their PATH, but they only have to do that once and
> it works consistently going forward, and they can still use the other
> program.

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 and set
the needed Conflicts. In this way we allow both packages to be installed
at the same time while leaving the users enough freedom to chose what to
have in their PATH.

As we want the packages to be discoverable, I would name them something
like this:

-debcompat (for "compatible with the other Debian packages"):
installs binaries in /usr/share//bin, does not set Conflicts,
warns the user in the Description, Suggests .

: installs the /usr/bin symlinks, sets the required Conflicts,
depends on -compat.

I would avoid the "-legacy" suffix, as it suggests that something is
outdated.

A "first come best served, modulo a different debian-devel consensus,
modulo CTTE" policy could be good enough to decide which package
deserves to install the "real" binary in /usr/bin.

We have to recognize that there is no perfect solution here. If we
enforce the rename it will often be a big hassle for several people for
a little gain while still leaving room for ambiguity (e.g. user set-up
aliases and symlinks). On the other side if we allow Conflicts to be
always used we will end up having useful but incompatible packages. I
think the best compromise is somewhere in between.

Paride

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Sune Vuorela]

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 I missing a key reason for this?

If we allow conflicts in this case, we disallow users to use both tools
at the same time.

And on multiple-users machines, it is kind of a random what tool they
actually get when they invoke a binary.

I think that is a disservice to our users.

Suddenly getting a sudo clone invoked when you want your build to build
fast is kind of .. suprising.

/Sune

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Andrey Rahmatullin]

On Sat, Sep 08, 2018 at 06:07:43PM -0300, David Bremner wrote:
> Andrey Rahmatullin  writes:
> 
> > Last upload of ax25-node was in 2008, in 2009 it was effectively orphaned,
> > the TC bug was filed in 2011 and resolved in 2012, in 2015 ax25-node was
> > removed with "ROM; no activity, open security issues, de facto orphaned"
> > (the status that was true when the TC bug was filed). In 2017 the previous
> > TC decision was repealed.
> 
> To be clear, the TC knew that ax25-node was removed when they (we)
> repealed the previous decision. 
Sure.
I mean the package could have been removed in 2010 instead.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Guillem Jover]

Hi!

On Sat, 2018-09-08 at 20:18:10 +0200, Sylvestre Ledru wrote:
> Le 08/09/2018 à 18:39, Sean Whitton a écrit :
> > On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote:
> > > However, I think the policy gives us a lot of freedom to choose (it
> > > is not very strict in this case).
> > 
> > I don't understand.  This seems pretty strict:
> > 
> > Two different packages must not install programs with different
> > functionality but with the same filenames.

> I think the policy should be changed.

I'd very very strongly oppose any such change.

It's also sad to see that the tech-ctte decision on the node non-problem
seems to have created, for some, such very bad precedent. :(

> It was possible to accommodate that when the archive was a few thousand
> packages. Now that it is much bigger, that floss are everywhere,
> packages are being forked, we might want to update the policy to give
> more flexibility.

Precisely now, with so many packages, it's way more important than ever
to keep such policy, compared to earlier times where such potential
conflicts could have been possibly tracked and managed more easily.

> Renaming binaries is a big pain, it is confusing for the user, making
> the life of the maintainer harder, the documentations won't reflect
> the Debian-reality.

With a shared namespace like PATH, and a global uncoordinated amount
of upstreams assigning names autonomously, user confusion is guaranteed
outside of the realms of Debian, where we are the designated guardians
of this namespace. Let's not make it worse for ourselves, just because
that mess is uncontrollable outside our boundaries.

> The wording should be changed from "must" to "should":
> ---
> Two different packages should not install programs with different
> functionality but with the same filenames.
> ---
> and give more flexibility to maintainers.

That would, IMO, be catastrophic.

> Or am I missing a key reason for this?

Yes. The PATH namespace provides a (time-bound) contract with a set of
interfaces. Those interfaces are exposed by name. When we use something
like update-alternatives, dpkg-divert or Conflicts we do that only for
compatible interfaces, even though the underlying implementations might
support more functionality (such as dash vs bash for /bin/sh).

Using any of the above methods to provide different interfaces on the
same name would cause untold breakage and confusion in user minds,
systems, programs and subvert the dependency system.

Say for example a user has local program relying on such interface, and
one admin replaces it with a conflicting interface; one thing is the
interface going missing the other is it starting to do something
completely different. Or a package Recommends/Suggests one of these
alternative interfaces, now you'd need to track any such recommends
and add Conflicts to any of these packages, otherwise they might
optionally try to use them and stop working, or cause damage, etc. This
then would leak this information all over the dependency graph. Not to
mention making different subgraphs completely unavailable due to do
those Conflicts.

Also, above I say time-bound, because it's actually fine (if handled
correctly) to reuse a specific name for different interfaces in different
Debian releases, because the contracts are different and non-changing
within those time-boundaries.

Thanks,
Guillem

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Russ Allbery]

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 user happier. This is especially true with low popcon packages
> with a small use case intersection.

If the packages conflict, though, this is extremely unfriendly to the
users who do want to use both packages.  They cannot use both packages on
the same OS installation, and have to resort to chroots or VMs or
containers, which is a lot of extra complexity.  I'm therefore in favor of
keeping Policy's prohibition on using Conflicts for this case; maybe a
combination of two packages will get lucky and there will be literally no
users who want to use both at the same time, but it's very hard to tell
when that's the case and the failure mode is ugly.

I kind of like the solution of putting the binaries in a different
directory.  This is also a little irritating, since users have to add an
additional directory to their PATH, but they only have to do that once and
it works consistently going forward, and they can still use the other
program.

It's not totally unheard of to have to modify PATH to use a package,
particularly one that wants to use a bunch of very generic command names.
That was always the official way to use MH, for example.

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

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Kurt Kremitzki]

> Hello,
> 
> On Sat 08 Sep 2018 at 07:31PM +0200, Ruben Undheim wrote:
> 
>> Yes, you are right, when I read it again. What I have been "reading" before 
>> is.
>>
>>  "Two different packages must not install programs with different 
>> functionality
>>  but with the same filenames if they do not declare that they "Conflict:" 
>> with
>>  each other."
>>
>> But it doesn't say that..
>>
>> So this means there is no way to provide the upstream executable name without
>> violating the policy? :( - even when using "Conflict:" wisely.
> 
> Yes -- the point is to have a single namespace.
> 
> As David mentioned, you should get in touch with the maintainers of the
> other package; it's likely you can come to some agreement.
> 
> -- 
> Sean Whitton

I've been maintaining netgen lately, and I've been watching the
conversation but not piping up as I'm still comparatively new as an
"only almost nearly" DM [1].

In general I'm open to proposed solutions, so long as it's kept in mind
that netgen is a sufficiently generic name that I doubt this will be the
last instance of collision for the binary. Probably as a result of the
naming problem, nowadays upstream has rebranded the project as NGSolve
[2], of which Netgen is just a component.

Originally my thought was to update the package to install the binary
to, say, /usr/bin/netgen-mesher, and use the alternatives system to
provide a "netgen-binary" as /usr/bin/netgen. However, it was previously
stated this wouldn't be the correct solution, so I don't know.

[1] https://nm.debian.org/process/541
[2] https://ngsolve.org

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Martin Steigerwald]

Sean Whitton - 08.09.18, 21:03:
> My understanding is that there are quite deep social reasons for the
> current policy (please note, though, that I was not involved in Debian
> when this piece of policy was created; neither was I involved during
> the nodejs TC decision).
> 
> 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.
> 
> The current policy means that the discussion about which package
> should use the name begins on neutral ground, without prejudice
> against the less popular package.  By requiring that they both change
> their names if agreement cannot be reached, the maintainers put on
> equal footing.
> 
> To my mind, this is part of our attempt to be "the universal operating
> system".

I wonder about a mechanism similar to update-alternatives or divert and 
then warn the user on binary name clashes on installing a package and 
offering her to rename one or both. So he can decide whether to have 
that rust based fd or the fdclone based fd command as fd and the other 
one as some other name.

Of course that would break scripts that expect a certain name. But for 
one of the packages the binary name would change anyway, so that happens 
in either case. But still, letting to user choose would mean that 
different installations behave differently. But we have that with 
update-alternatives for certain binaries anyway already.

-- 
Martin

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[David Bremner]

Andrey Rahmatullin  writes:

> Last upload of ax25-node was in 2008, in 2009 it was effectively orphaned,
> the TC bug was filed in 2011 and resolved in 2012, in 2015 ax25-node was
> removed with "ROM; no activity, open security issues, de facto orphaned"
> (the status that was true when the TC bug was filed). In 2017 the previous
> TC decision was repealed.

To be clear, the TC knew that ax25-node was removed when they (we)
repealed the previous decision. 


signature.asc
Description: PGP signature

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Ruben Undheim]

> stupid idea:
> 
> do these scripts (and other consumers of the netgen binaries) actually
> use the fully qualified "/usr/bin/netgen" or just an unqualified "netgen"?
> 
> if the latter, you might just put the unchanged names into something
> like /usr/share/netgen/bin/ and tell users to add to that to their PATH
> when running their scripts.
> that provides a simple compat layer for out-of-distro scripts.
> rdeps in Debian should be patched to use debianized script-names.

Thanks, IOhannes

This may actually turn out to be the best idea if the policy is not changed as
a result of the discussion that has started. :)

Ruben

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Ruben Undheim]

Hi David,

> I may have missed it, but it looks like you didn’t ask directly the
> netgen maintainers (or explicitly CC them during this discussion). Maybe
> a first good step is to communicate with them and ask what is their take
> on that matter

If there is no way to actually share a file name without breaking the policy,
there is not anything we alone can agree on without involving the whole
community. I have absolutely no intention of stealing the /usr/bin/netgen from
them ;)

I have not asked the netgen maintainers directly, because the proposed package
upload of netgen-lvs would not have a direct impact on that package. Also, I
also consider debian-devel an open forum, assuming they also read here if
interested (probably too naive of me). :)

> (trying to find a consensus without half of the involved
> party may be considered as rude, that’s probably not your intention).

Absolutely not my intention.

Thanks for pointing it out. You are probably right, but if I were the netgen
maintainer, I could probably just as well think it would be rude to be
contacted to be asked to "share" a file name, when it can be solved without
involving me - and it does not directly impact my package. :)


Thanks again!

Best regards,
Ruben

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Paride Legovini]

Hello Sean,

Sean Whitton wrote on 08/09/2018:
> Hello Sylvestre,
> 
> On Sat 08 Sep 2018 at 08:18PM +0200, Sylvestre Ledru wrote:
> 
>> Renaming binaries is a big pain, it is confusing for the user, making the 
>> life of the maintainer
>> harder, the documentations won't reflect the Debian-reality.
>>
>> The wording should be changed from "must" to "should":
>> ---
>> Two different packages should not install programs with different
>> functionality but with the same filenames.
>> ---
>> and give more flexibility to maintainers.
>>
>> Or am I missing a key reason for this?
> 
> My understanding is that there are quite deep social reasons for the
> current policy (please note, though, that I was not involved in Debian
> when this piece of policy was created; neither was I involved during the
> nodejs TC decision).
> 
> 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.
> 
> The current policy means that the discussion about which package should
> use the name begins on neutral ground, without prejudice against the
> less popular package.  By requiring that they both change their names if
> agreement cannot be reached, the maintainers put on equal footing.
> 
> To my mind, this is part of our attempt to be "the universal operating
> system".

These are all sensible reasons, and I think the policy has been written
in the way it is after carefully pondering all the options.

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 user happier. This is especially true with low popcon packages
with a small use case intersection.

I find policy too strict on this point, and I would favor it to be
somehow relaxed or allow other options.

Paride



signature.asc
Description: OpenPGP digital signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Ruben Undheim]

Hi,

> > Renaming binaries is a big pain, it is confusing for the user, making the 
> > life of the maintainer
> > harder, the documentations won't reflect the Debian-reality.
> >
> > The wording should be changed from "must" to "should":
> > ---
> > Two different packages should not install programs with different
> > functionality but with the same filenames.
> > ---
> > and give more flexibility to maintainers.
> >
> > Or am I missing a key reason for this?
> 
> 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.

In this discussion, I would like to distinguish between package names and file
names for files in a package. For package names, it makes completely sense that
the first package to enter the archive is entitled to have exclusive rights to
the name, even though a more popular package which appears later would have the
same upstream name. That helps users of less popular packages to not feel that
their package is less important in Debian.

If the later and more popular package will need a "name compatibility package"
such as nodejs-legacy to provide the correct upstream executable name, the
users of the less popular package will still not feel (I assume) that their
package is less important in Debian.

> The current policy means that the discussion about which package should
> use the name begins on neutral ground, without prejudice against the
> less popular package.  By requiring that they both change their names if
> agreement cannot be reached, the maintainers put on equal footing.
 
> To my mind, this is part of our attempt to be "the universal operating
> system".

My take on it is that having no way to provide the executable name which users
expect (with name compatibilty packages such as nodejs-legacy was) makes the
operating system less "universal" in a way.


Cheers,
Ruben

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Andrey Rahmatullin]

On Sat, Sep 08, 2018 at 12:03:18PM -0700, Sean Whitton wrote:
> My understanding is that there are quite deep social reasons for the
> current policy (please note, though, that I was not involved in Debian
> when this piece of policy was created; neither was I involved during the
> nodejs TC decision).
> 
> 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.
Still, the nodejs case was, at least to a casual observer, only a massive
waste of time and nerves.

Last upload of ax25-node was in 2008, in 2009 it was effectively orphaned,
the TC bug was filed in 2011 and resolved in 2012, in 2015 ax25-node was
removed with "ROM; no activity, open security issues, de facto orphaned"
(the status that was true when the TC bug was filed). In 2017 the previous
TC decision was repealed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Sean Whitton]

Hello Sylvestre,

On Sat 08 Sep 2018 at 08:18PM +0200, Sylvestre Ledru wrote:

> Renaming binaries is a big pain, it is confusing for the user, making the 
> life of the maintainer
> harder, the documentations won't reflect the Debian-reality.
>
> The wording should be changed from "must" to "should":
> ---
> Two different packages should not install programs with different
> functionality but with the same filenames.
> ---
> and give more flexibility to maintainers.
>
> Or am I missing a key reason for this?

My understanding is that there are quite deep social reasons for the
current policy (please note, though, that I was not involved in Debian
when this piece of policy was created; neither was I involved during the
nodejs TC decision).

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.

The current policy means that the discussion about which package should
use the name begins on neutral ground, without prejudice against the
less popular package.  By requiring that they both change their names if
agreement cannot be reached, the maintainers put on equal footing.

To my mind, this is part of our attempt to be "the universal operating
system".

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Shengjing Zhu]

On Sun, Sep 9, 2018 at 2:29 AM Sylvestre Ledru  wrote:
>
> Hello,
>
> Le 08/09/2018 à 18:39, Sean Whitton a écrit :
> > Hello,
> >
> > On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote:
> >
> >> However, I think the policy gives us a lot of freedom to choose (it is not 
> >> very
> >> strict in this case).
> >
> > I don't understand.  This seems pretty strict:
> >
> > 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.
> Now that it is much bigger, that floss are everywhere, packages are being 
> forked,

This is indeed annoy nowadays. And on the other hand, many software
authors don't take serious on naming, just picking some common words.

But I see it's problem in FHS, which has one namespace for binary.

> we might want to update the policy to give more flexibility.
> 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, fdclone a clone
> of fd, a MS-DOS file browser...
> While this is probably fun, with a declining popcon (104 today), and no 
> upstream release since 2013,

It's not true, at least I find the latest release is last month[1]

[1] http://www.unixusers.net/ml/FDclone-users/201808/msg0.html (in Japanese)


--
Shengjing Zhu

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Sean Whitton]

Hello,

On Sat 08 Sep 2018 at 07:31PM +0200, Ruben Undheim wrote:

> Yes, you are right, when I read it again. What I have been "reading" before 
> is.
>
>  "Two different packages must not install programs with different 
> functionality
>  but with the same filenames if they do not declare that they "Conflict:" with
>  each other."
>
> But it doesn't say that..
>
> So this means there is no way to provide the upstream executable name without
> violating the policy? :( - even when using "Conflict:" wisely.

Yes -- the point is to have a single namespace.

As David mentioned, you should get in touch with the maintainers of the
other package; it's likely you can come to some agreement.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

[Sylvestre Ledru]

Hello,

Le 08/09/2018 à 18:39, Sean Whitton a écrit :
> Hello,
> 
> On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote:
> 
>> However, I think the policy gives us a lot of freedom to choose (it is not 
>> very
>> strict in this case).
> 
> I don't understand.  This seems pretty strict:
> 
> 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.
Now that it is much bigger, that floss are everywhere, packages are being 
forked,
we might want to update the policy to give more flexibility.
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, fdclone a clone
of fd, a MS-DOS file browser...
While this is probably fun, with a declining popcon (104 today), and no 
upstream release since 2013,
I am not sure it is relevant to reverse the path for a leaf packages like this 
one.

Renaming binaries is a big pain, it is confusing for the user, making the life 
of the maintainer
harder, the documentations won't reflect the Debian-reality.

The wording should be changed from "must" to "should":
---
Two different packages should not install programs with different
functionality but with the same filenames.
---
and give more flexibility to maintainers.

Or am I missing a key reason for this?

Cheers,
Sylvestre

[1] https://github.com/sharkdp/fd
[2] https://tracker.debian.org/pkg/fdclone

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[David Prévot]

Le 08/09/2018 à 07:31, Ruben Undheim a écrit :

> And it also means that the package pair "nodejs-legacy" and "node" was RC
> buggy when the packages were present (jessie I guess)

You may have a look at the TC ruling for a bit of context for node.

https://bugs.debian.org/614907

> Does anyone know about other packages this applies for? Any easy way to search
> the archive for packages that provide files with the same name?

Not answering that question specifically, but for example, chromium was
renamed as chromium-bsu (upstream). chromium-browser used to be
available via /usr/bin/chromium-browser for a while.

I may have missed it, but it looks like you didn’t ask directly the
netgen maintainers (or explicitly CC them during this discussion). Maybe
a first good step is to communicate with them and ask what is their take
on that matter (trying to find a consensus without half of the involved
party may be considered as rude, that’s probably not your intention).

Regards

David



signature.asc
Description: OpenPGP digital signature

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Ruben Undheim]

Hi Sean,

> > However, I think the policy gives us a lot of freedom to choose (it is not 
> > very
> > strict in this case).
> 
> I don't understand.  This seems pretty strict:
> 
> Two different packages must not install programs with different
> functionality but with the same filenames.

Yes, you are right, when I read it again. What I have been "reading" before is.

 "Two different packages must not install programs with different functionality
 but with the same filenames if they do not declare that they "Conflict:" with
 each other."

But it doesn't say that..

So this means there is no way to provide the upstream executable name without
violating the policy? :( - even when using "Conflict:" wisely.


> > The alternatives system is supposed to be used for packages which
> > provide similar functionality (as far as I have understood), and that
> > is absolutely not the case here.
> 
> Right, alternatives is not for this.
> 
> > 5. The netgen-lvs binary package provides basically just a symlink from
> >/usr/bin/netgen to /usr/bin/netgen-lvs
> 
> To my mind, this straightforwardly violates the sentence from Policy
> quoted above, and would thus be RC-buggy.

And it also means that the package pair "nodejs-legacy" and "node" was RC
buggy when the packages were present (jessie I guess)


Does anyone know about other packages this applies for? Any easy way to search
the archive for packages that provide files with the same name?


Cheers
Ruben

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Sean Whitton]

Hello,

On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote:

> However, I think the policy gives us a lot of freedom to choose (it is not 
> very
> strict in this case).

I don't understand.  This seems pretty strict:

Two different packages must not install programs with different
functionality but with the same filenames.

> The alternatives system is supposed to be used for packages which
> provide similar functionality (as far as I have understood), and that
> is absolutely not the case here.

Right, alternatives is not for this.

> 5. The netgen-lvs binary package provides basically just a symlink from
>/usr/bin/netgen to /usr/bin/netgen-lvs

To my mind, this straightforwardly violates the sentence from Policy
quoted above, and would thus be RC-buggy.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Debian/GNU]

On 9/7/18 10:10 PM, Ruben Undheim wrote:
> 3. The netgen-lvs-base binary package comes with all the (main) files for
>netgen-lvs. The executable will be called /usr/bin/netgen-lvs
>It will NOT conflict with "netgen".
> 
> 4. the netgen-lvs source package will be patched such that it works with the
>executable called /usr/bin/netgen-lvs (there are some tcl scripts and 
> python
>scripts)

stupid idea:

do these scripts (and other consumers of the netgen binaries) actually
use the fully qualified "/usr/bin/netgen" or just an unqualified "netgen"?

if the latter, you might just put the unchanged names into something
like /usr/share/netgen/bin/ and tell users to add to that to their PATH
when running their scripts.
that provides a simple compat layer for out-of-distro scripts.
rdeps in Debian should be patched to use debianized script-names.

gfdasr
IOhannes



signature.asc
Description: OpenPGP digital signature

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Ruben Undheim]

>> What is the recommendation? Any links to previous discussions / documents 
>> about
>> this subject?
> Policy 10.1.

Thanks Andrey for pointing out the relevant policy chapter. I should have
mentioned it in my first post since exactly that section in a way brought me to
this list.

However, I think the policy gives us a lot of freedom to choose (it is not very
strict in this case). The alternatives system is supposed to be used for
packages which provide similar functionality (as far as I have understood), and
that is absolutely not the case here.


Let me do it this way then: I will propose what I intend to do with netgen-lvs
(what i think may be best), and then we will see if anyone has better ideas. :)


1. The new source package netgen-lvs will contain two binary packages:
  - netgen-lvs
  - netgen-lvs-base

2. netgen-lvs  will have a Conflict: netgen (existing unrelated package).

3. The netgen-lvs-base binary package comes with all the (main) files for
   netgen-lvs. The executable will be called /usr/bin/netgen-lvs
   It will NOT conflict with "netgen".

4. the netgen-lvs source package will be patched such that it works with the
   executable called /usr/bin/netgen-lvs (there are some tcl scripts and python
   scripts)

5. The netgen-lvs binary package provides basically just a symlink from
   /usr/bin/netgen to /usr/bin/netgen-lvs

6. The netgen-lvs binary package depends on netgen-lvs-base

7. A paragraph is added to the long description for netgen-lvs which explains 
that
   it conflicts with netgen (3d tetrahedral mesh generator), and if both are
   supposed to be installed at the same time, the package netgen-lvs-base must 
be
   installed instead of netgen-lvs.


Also:

i.   A similar paragraph in the long description can later be added to netgen's
 long description.

ii.  A "Conflict: netgen-lvs" should be added to netgen later.

iii. Maybe in the future, the "netgen" package can provide a similar 
"alternative
 binary package" for people who would like to have both netgen and 
netgen-lvs
 installed, but /usr/bin/netgen representing netgen-lvs


This will allow people to run "apt install netgen-lvs" and they will get a
netgen install which behaves exactly as the upstream version. (usr/bin/netgen
is what they think it is)

This still allows people to have both netgen and netgen-lvs(source) installed, 
but
then netgen-lvs will be found as /usr/bin/netgen-lvs.

I know that the alternatives system can technically be used to achieve similar
functionality, but it feels like it is meant only for cases where the various
programs provide similar functionality, and therefore not for this case.



Best regards
Ruben

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

[Andrey Rahmatullin]

On Tue, Sep 04, 2018 at 09:39:39PM +0200, Ruben Undheim wrote:
> What is the recommendation? Any links to previous discussions / documents 
> about
> this subject?
Policy 10.1.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: New package, name recycling

[Julien Cristau]

On Fri, Oct 20, 2017 at 16:59:58 +0200, W. Martin Borgert wrote:

> Hi,
> 
> just to be sure, that this is not a problem:
> 
> There used to be a package "dino" in Debian until jessie.  Upstream
> development dried up years ago and dino became extinct.
> 
> Recently, a new "dino" appeared on the surface of earth, which is a
> completely different program. Like git vs git or node vs node, but
> with only one contender.
> 
> I would package the new dino under this name, because I don't think
> there is a conflict.
> 
> Any objections?
> 
I think reusing package names for a different purpose is very bad, in
almost all cases.  Pretty sure including this one.

Cheers,
Julien

Re: New package, name recycling

[Adam Borowski]

On Sun, Oct 22, 2017 at 11:02:31PM +0100, Ian Jackson wrote:
> FAOD: although "." is legal in package names, I agree that it should
> not be used here.  We don't want to embed upstream's domain names in
> our package names because the former have a very short lifespan (!)
> - often much shorter than the lifespan of a Debian package.

Yeah, it's a terrible idea.  But there's something nasty I can tell you
about what appears to be a set of packages implementing golang's interfaces
to github...

-- 
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. 
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.

Re: New package, name recycling

[Thomas Goirand]

On 10/21/2017 11:45 AM, Christoph Biedl wrote:
> Also: Reject NEW packages with
> short names (say, less than six characters) since it's quite likely they
> will collide semantically with something else.

If the name is used upstream, and there's no collision, I really don't
see why we'd do something like this. The "will collide" is a wild guess,
and ever will be.

There's about 1000 packages in Stretch with 4 chars or less in the name,
and so far, so good...

Cheers,

Thomas Goirand (zigo)

Re: New package, name recycling

[Ian Jackson]

W. Martin Borgert writes ("Re: New package, name recycling"):
> On 2017-10-20 16:59, W. Martin Borgert wrote:
> > I would package the new dino under this name, because I don't think
> > there is a conflict.
> 
> OK, I will better not reuse the name, but go for dino-im (= dino
> instant messenger), which fits with its domain name dino.im.

FAOD: although "." is legal in package names, I agree that it should
not be used here.  We don't want to embed upstream's domain names in
our package names because the former have a very short lifespan (!)
- often much shorter than the lifespan of a Debian package.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: New package, name recycling

[W. Martin Borgert]

On 2017-10-20 16:59, W. Martin Borgert wrote:
> I would package the new dino under this name, because I don't think
> there is a conflict.

OK, I will better not reuse the name, but go for dino-im (= dino
instant messenger), which fits with its domain name dino.im.

Thanks for all your input!

Re: New package, name recycling

[Anthony DeRobertis]

It's still in a supported release (Jessie), two of you count LTS (wheezy). 
Reusing that name should probably wait until Jessie is out of LTS support 
otherwise there will be conflicts at least with the security tracker.

Re: New package, name recycling

[Michael Biebl]

Am 21.10.2017 um 11:45 schrieb Christoph Biedl:

> Or: Introduce package namespaces, this is a big change. The existing
> flat model one with somewhat hundred thousand (wild guess) entries over
> the past 25 years worked quite well most of the time, although not
> always (git, node). But it's obvious there is a problem in the very long
> run, and it seems wise to think about that before it becomes pressing.
> For a start, there is the Section: information, then a sound/dino and a
> net/dino could co-exist.

While that would solve the infrastructure (bts, pts,...) and package
management side, it's still very likely that you'd get file conflicts
like both shipping /usr/bin/dino


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: New package, name recycling

[Christoph Biedl]

Adam Borowski wrote...

> On Fri, Oct 20, 2017 at 11:42:04AM -0400, Jeremy Bicha wrote:
> > On Fri, Oct 20, 2017 at 10:59 AM, W. Martin Borgert  
> > wrote:
> > > I would package the new dino under this name, because I don't think
> > > there is a conflict.
> > 
> > It is a problem for Ubuntu unless the new version has a newer version
> > number than the old package.
> > 
> > Launchpad does not forget about old version numbers.
> 
> Neither does our PTS for packages in still supported releases, nor BTS ever,

Security tracker, and certainly many more tools that are not on radar.

> nor user machines that still have the extinct dino installed.  But that's
> easily fixable by making sure your version number is higher (use an epoch if
> you must).

Surprise to the users if they still use the old package - which they
shouldn't since it has been of support for a long time, but these things
happen.

Another surprise, if they found a recommendation for the old package but
get the new one.

> There is another concern: I'd refrain with reintroduction until at least one
> dino-less release.  Oh wait, stretch is already out.

In my opinion: Wait until the old package is burried and forgotten. So the
gap should rather be somewhat ten years.

Or: Never ever re-use a package name. Also: Reject NEW packages with
short names (say, less than six characters) since it's quite likely they
will collide semantically with something else.

Or: Introduce package namespaces, this is a big change. The existing
flat model one with somewhat hundred thousand (wild guess) entries over
the past 25 years worked quite well most of the time, although not
always (git, node). But it's obvious there is a problem in the very long
run, and it seems wise to think about that before it becomes pressing.
For a start, there is the Section: information, then a sound/dino and a
net/dino could co-exist.

Christoph


signature.asc
Description: Digital signature

Re: New package, name recycling

[Paul Wise]

On Fri, Oct 20, 2017 at 10:59 PM, W. Martin Borgert wrote:

> a package "dino" in Debian

This seems like a fairly generic name.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: New package, name recycling

[Adam Borowski]

On Fri, Oct 20, 2017 at 11:42:04AM -0400, Jeremy Bicha wrote:
> On Fri, Oct 20, 2017 at 10:59 AM, W. Martin Borgert  
> wrote:
> > I would package the new dino under this name, because I don't think
> > there is a conflict.
> 
> It is a problem for Ubuntu unless the new version has a newer version
> number than the old package.
> 
> Launchpad does not forget about old version numbers.

Neither does our PTS for packages in still supported releases, nor BTS ever,
nor user machines that still have the extinct dino installed.  But that's
easily fixable by making sure your version number is higher (use an epoch if
you must).

There is another concern: I'd refrain with reintroduction until at least one
dino-less release.  Oh wait, stretch is already out.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. 
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.

Re: New package, name recycling

[Jeremy Bicha]

On Fri, Oct 20, 2017 at 10:59 AM, W. Martin Borgert  wrote:
> I would package the new dino under this name, because I don't think
> there is a conflict.

It is a problem for Ubuntu unless the new version has a newer version
number than the old package.

Launchpad does not forget about old version numbers.

For context, the new ITP is https://bugs.debian.org/860055

Thanks,
Jeremy Bicha

Re: New package split of util-linux

[Adam Borowski]

On Thu, Jul 27, 2017 at 12:32:24PM +0200, Andreas Henriksson wrote:
> On Wed, Jul 26, 2017 at 11:03:08AM +0200, Adam Borowski wrote:
> > But why should mount be Essential?  It's useless in containers and chroots.
> 
> I'm very open to making things non-essential if possible, not limited to
> only mount. (Why should bsdutils be essential for example? But how do we
> make it non-essential? Even if policy didn't forbid depending on
> essential packages, how would we even identify users that should add
> a dependency? See also #474540 for another example of this practical
> problem.)

https://wiki.debian.org/BusterPriorityRequalification has some interesting
discussion.

Making things non-Essential is indeed hard, but making them Important[1]
is easier as for most tools these two are considered synonymous.

As we're very early in Buster's cycle, a somewhat cavalier approach could
be acceptable: to degrade programs and see what breaks.  It's safe for
upgrades (tools really dislike removing Important) and for new regular
whole-machine installs; only uses that might have issues are chroots
and small containers.

> I aware of but have no practical experience with the Important: yes
> field. I can only guess and hope that if we use that for mount there
> won't be any weird upgrade problems. (Help welcome to verify it!)

I've done some research, and:

* user-facing tools support Important well enough, as of Stretch:
  while dpkg itself doesn't protest, frontends like apt, dselect, aptitude,
  synaptic, gnome-packagekit, apper are all _too_ paranoid here.  This is
  actually good for ordinary users -- converting a full machine to a
  container isn't exactly a common use case.

  The only frontend that doesn't stop you is cupt, but with popcon vote of
  23 it's not much of a concern, especially that you tend to remove Buster
  packages using Buster tools.

* on the other hand, current dpkg-gencontrol does not support this field

* the Policy doesn't mention it either


Thus: it's not legal to use Important yet but there are no blockers to
have it for Buster.


If you'd like to play some more, my test packages are in:
deb http://angband.pl/debian essimp main
(-src, https), key:
wget -qO- https://angband.pl/deb/archive.html|apt-key add -
"test-essential", "test-important"


> > What about making the split at different levels of essentialness?  With the
> > new Important: yes (not be confused with priority: important), this makes
> > three levels, and thus three packages:
> > * stuff that's needed on every Debian system
> > * stuff needed on every bare-metal box / "real" VM
> > * things you can go without
> 
> I would be very interested to see your resulting of this splitup!

As Steve Langasek mentioned, not all containers are alike.  Unlike old-style
implementations like vserver or openvz (even they let you allow ccaps
SECURE_MOUNT and BINARY_MOUNT), modern containers are a really fuzzy
concept, with a mix-and-match of chroot, cgroups, namespaces, seccomp.

But there's a pretty common set of things typical containers don't need.
They don't need to manipulate partitions, fsck, etc.  That's most of
util-linux's size.

> In theory I'm not really sure there's anything matching the "stuff
> that's needed on every Debian system" criteria in src:util-linux
> if considering less usual usecases.)

Yeah but a container has a host which can rescue it, and then you can
install anything you want into the container.  So it's about minimal
functionality only.


Meow!

[1]. A poorly chosen name, because of confusion with priority:important.
But AFAIK it was repurposing an ancient hidden feature rather than a new
design.
-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs (the five fishes + two breads affair)
⠈⠳⣄ • use glitches to walk on water

Re: New package split of util-linux

[Andreas Henriksson]

Hello Adam Borowski,

thanks for your feedback.

On Wed, Jul 26, 2017 at 11:03:08AM +0200, Adam Borowski wrote:
> But why should mount be Essential?  It's useless in containers and chroots.

I'm very open to making things non-essential if possible, not limited to
only mount. (Why should bsdutils be essential for example? But how do we
make it non-essential? Even if policy didn't forbid depending on
essential packages, how would we even identify users that should add
a dependency? See also #474540 for another example of this practical
problem.)

I aware of but have no practical experience with the Important: yes
field. I can only guess and hope that if we use that for mount there
won't be any weird upgrade problems. (Help welcome to verify it!)

One thing to consider first though might be if the findmnt utility
should be moved over to util-linux package (I likely put this tool in
the wrong place to begin with since it didn't matter much back then).
WDYT?

[...]
> What about making the split at different levels of essentialness?  With the
> new Important: yes (not be confused with priority: important), this makes
> three levels, and thus three packages:
> * stuff that's needed on every Debian system
> * stuff needed on every bare-metal box / "real" VM
> * things you can go without

I would be very interested to see your resulting of this splitup!

Also please consider it in the light of the previous criterias I posted.
(Because suggesting something better which have doable upgrade path from
the current state is problematic from a practical perspective.
In theory I'm not really sure there's anything matching the "stuff
that's needed on every Debian system" criteria in src:util-linux
if considering less usual usecases.)

Regards,
Andreas Henriksson

Re: New package split of util-linux

[Steve Langasek]

On Wed, Jul 26, 2017 at 11:03:08AM +0200, Adam Borowski wrote:
> On Wed, Jul 26, 2017 at 10:18:46AM +0200, Andreas Henriksson wrote:
> > I'm looking for help with ideas about a new package split for the
> > util-linux suite.

> > Currently the main binary packages are:
> > util-linux
> > mount
> > bsdutils
> > (Then there are a bunch of other less important binary packages also
> > built.)

> > All of the three above packages have the Essential: yes control field
> > set.  This basically means when ever upstream writes a new tool and we
> > decide to ship it, it instantly becomes part of the essential set.

> > I also don't see any real reason for the mount package to be separate
> > from the util-linux package.

> But why should mount be Essential?  It's useless in containers and chroots.

That's not true.  It is not /required/ for basic operation of containers and
chroots, which is maybe what you meant, but that doesn't mean it's useless.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: New package split of util-linux

[Adam Borowski]

On Wed, Jul 26, 2017 at 10:18:46AM +0200, Andreas Henriksson wrote:
> I'm looking for help with ideas about a new package split for the
> util-linux suite.
> 
> Currently the main binary packages are:
> util-linux
> mount
> bsdutils
> (Then there are a bunch of other less important binary packages also
> built.)
 
> All of the three above packages have the Essential: yes control field
> set.  This basically means when ever upstream writes a new tool and we
> decide to ship it, it instantly becomes part of the essential set.
 
> I also don't see any real reason for the mount package to be separate
> from the util-linux package.

But why should mount be Essential?  It's useless in containers and chroots.
 
> In short, I'm considering a new package split to be needed.
 
> If people have ideas or suggestions about this package split I'm
> interested to hear them.

What about making the split at different levels of essentialness?  With the
new Important: yes (not be confused with priority: important), this makes
three levels, and thus three packages:
* stuff that's needed on every Debian system
* stuff needed on every bare-metal box / "real" VM
* things you can go without


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs (the five fishes + two breads affair)
⠈⠳⣄ • use glitches to walk on water

Re: New package tracker - old one going?

[Paul Wise]

On Tue, Sep 16, 2014 at 5:15 AM, Iain R. Learmonth wrote:

 I notice that packages.qa.debian.org is advertising the new package tracker.
 Does this mean the old package tracker there is going to disappear?

It will go away eventually once the new tracker has equivalent functionality.

 I was going to build something for tracking team packages using the RDF
 generated by the tracker at packages.qa.debian.org but if it's going to
 disappear I'll have to find another way.

If you could help port the RDF work to the new tracker that would help
the transition move faster and also give you a reliable source of data
for both Debian and derivatives who also use the same software.
Another option is to base your team thing on UDD.

https://udd.debian.org/

BTW we already have several team things, could you just use those?

http://pet.debian.net/
https://udd.debian.org/dmd.cgi
https://tracker.debian.org/teams/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6f3fvrv_+8phghra_hn8p-pgdxmkh_aylczbf7k-fl...@mail.gmail.com

Re: New package tracker - old one going?

[Andreas Tille]

Hi,

On Tue, Sep 16, 2014 at 02:54:43PM +0800, Paul Wise wrote:
 Another option is to base your team thing on UDD.
 
 https://udd.debian.org/

While I have no idea about the specific purpose but I'd recommend to
use UDD as source of information.

Kind regards

 Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140916074056.ge4...@an3as.eu

Re: New package tracker - old one going?

[Raphael Hertzog]

Hi,

On Mon, 15 Sep 2014, Iain R. Learmonth wrote:
 I notice that packages.qa.debian.org is advertising the new package tracker.
 Does this mean the old package tracker there is going to disappear?

At some point, yes.

 I was going to build something for tracking team packages using the RDF
 generated by the tracker at packages.qa.debian.org but if it's going to
 disappear I'll have to find another way.

The new tracker.d.o has a concept of teams[1] grouping multiple packages
already. Right now it's only useful to subscribe to all packages of the
team at once but I would like to see this extended to feature a full
blown tracker like PET.

What kind of features were you planning into your own tracker?

[1] https://tracker.debian.org/teams/

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140916075847.ge25...@x230-buxy.home.ouaza.com

teams in Re: New package tracker - old one going?

[Holger Levsen]

Hi,

On Dienstag, 16. September 2014, Paul Wise wrote:
 https://tracker.debian.org/teams/

how is that fed with data? 

I notice most teams from wiki.d.o/Teams/ are missing :/


cheers,
Holger





signature.asc
Description: This is a digitally signed message part.

Re: teams in Re: New package tracker - old one going?

[Paul Wise]

On Tue, Sep 16, 2014 at 5:47 PM, Holger Levsen wrote:

 how is that fed with data?

https://tracker.debian.org/teams/+create/

 I notice most teams from wiki.d.o/Teams/ are missing :/

Up to each team if they want to use the tracker, few have chosen to do so.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6e-jmhcpq7wpgwpnq_ucmtqquojsveada8ryrht3+9...@mail.gmail.com

Re: teams in Re: New package tracker - old one going?

[Stefano Zacchiroli]

On Tue, Sep 16, 2014 at 05:54:15PM +0800, Paul Wise wrote:
 On Tue, Sep 16, 2014 at 5:47 PM, Holger Levsen wrote:
  how is that fed with data?
 https://tracker.debian.org/teams/+create/
 
  I notice most teams from wiki.d.o/Teams/ are missing :/
 Up to each team if they want to use the tracker, few have chosen to do so.

Yeah well, I suspect most teams simply don't know about this feature.

AFAICT tracker.d.o as a whole (let aside the team feature) has not even
been announced to d-d-a yet.  Maybe it's time to do that, highlighting
specific opt-in features such as team claiming?

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: New package tracker - old one going?

[Iain R. Learmonth]

On Tue, Sep 16, 2014 at 02:54:43PM +0800, Paul Wise wrote:
 It will go away eventually once the new tracker has equivalent functionality.

I know it's nothing to be abandoning the new tracker over, but the new one
hurts my eyes. The old one is quite pretty.

 If you could help port the RDF work to the new tracker that would help
 the transition move faster and also give you a reliable source of data
 for both Debian and derivatives who also use the same software.

If it still needs to be done the next time I find myself short of things to
do, I will take a look.

 Another option is to base your team thing on UDD.
 https://udd.debian.org/

Did not know about this, this looks to be a useful source of information.

 BTW we already have several team things, could you just use those?

I didn't know about these but I've had a look at them and they're not really
what I'm looking for. I was thinking something similar to the blends web
sentinels, but with a focus on being useful for end users too. Grouping the
packages into categories for the functions they provide similar to the
blends tasks so you can get an easy overview of all the packages in an
area, and then contibutors can also see where areas are needing work.

Iain.

-- 
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: +447875886930
c: MM6MVQ  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49


pgpnF0V8_KL19.pgp
Description: PGP signature

Re: New package tracker - old one going?

[Iain R. Learmonth]

On Tue, Sep 16, 2014 at 11:41:26AM +0100, Iain R. Learmonth wrote:
 I didn't know about these but I've had a look at them and they're not really
 what I'm looking for. I was thinking something similar to the blends web
 sentinels, but with a focus on being useful for end users too. Grouping the
 packages into categories for the functions they provide similar to the
 blends tasks so you can get an easy overview of all the packages in an
 area, and then contibutors can also see where areas are needing work.

Saying this, if the ham radio team is willing to look into becoming a blend,
then we would gain this anyway, and any missing features I was thinking of
could be added to the blends web sentinel.

Iain.

-- 
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: +447875886930
c: MM6MVQ  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49


pgpdeQhZX4Znf.pgp
Description: PGP signature

Re: New package tracker - old one going?

[Colin Tuckley]

On 16/09/14 11:46, Iain R. Learmonth wrote:

 Saying this, if the ham radio team is willing to look into becoming a blend,
 then we would gain this anyway, and any missing features I was thinking of
 could be added to the blends web sentinel.

At the moment the team doesn't even seem to have time to maintain the
groups packages. Until I started work on them a couple of months ago
most of them hadn't been touched for several years since Joop retired.

I'm not sure how many of the team are actually active any more.

Colin

-- 
Colin Tuckley  |  +44(0)1223 830814  |  PGP/GnuPG Key Id
Debian Developer   |  +44(0)7799 143369  | 0x38C9D903




signature.asc
Description: OpenPGP digital signature

Re: New package tracker - old one going?

[Raphael Hertzog]

Hi,

On Tue, 16 Sep 2014, Iain R. Learmonth wrote:
 On Tue, Sep 16, 2014 at 02:54:43PM +0800, Paul Wise wrote:
  It will go away eventually once the new tracker has equivalent 
  functionality.
 
 I know it's nothing to be abandoning the new tracker over, but the new one
 hurts my eyes. The old one is quite pretty.

That's not a very actionable feedback. The main differences are:
- white background instead of gray one
- more whitespace between panels
- smaller font-size (this has already been reported in #756721

What parts are actually problematic in your opinion ?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140916114436.ge23...@x230-buxy.home.ouaza.com

Re: New package tracker - old one going?

[Iain R. Learmonth]

On Tue, Sep 16, 2014 at 01:44:36PM +0200, Raphael Hertzog wrote:
 On Tue, 16 Sep 2014, Iain R. Learmonth wrote:
  I know it's nothing to be abandoning the new tracker over, but the new one
  hurts my eyes. The old one is quite pretty.
 
 That's not a very actionable feedback. The main differences are:
 What parts are actually problematic in your opinion ?

It's just a bit too bright. Maybe it is the change in background colour
that's done this, coupled with the red. It's possible this is just my laptop
screen. I think before the grey background helped to seperate out the boxes
and make it easier to read too.

Also, the spacing seems to be off, buttons misaligned, all the things that
generally go wrong when you hack something together with bootstrap without a
degree in web design. These are things that bug me but don't affect my
ability to use it and probably do not need to be fixed unless someone really
wants to.

Iain.

-- 
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: +447875886930
c: MM6MVQ  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49


pgpnwyB08eojp.pgp
Description: PGP signature

Re: New package tracker - old one going?

[Scott Kitterman]

On September 16, 2014 7:44:36 AM EDT, Raphael Hertzog hert...@debian.org 
wrote:
Hi,

On Tue, 16 Sep 2014, Iain R. Learmonth wrote:
 On Tue, Sep 16, 2014 at 02:54:43PM +0800, Paul Wise wrote:
  It will go away eventually once the new tracker has equivalent
functionality.
 
 I know it's nothing to be abandoning the new tracker over, but the
new one
 hurts my eyes. The old one is quite pretty.

That's not a very actionable feedback. The main differences are:
- white background instead of gray one
- more whitespace between panels
- smaller font-size (this has already been reported in #756721

What parts are actually problematic in your opinion ?

In mine, the top center panel being taken up by information about the new 
tracker makes it quite difficult to really get a feel for how readable/usable 
the new site is. Is there some way to make that removable? 

Scott K



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/0135d94d-20ae-4a3e-8a9b-fe03b82fb...@email.android.com

Re: teams in Re: New package tracker - old one going?

[Andreas Tille]

On Tue, Sep 16, 2014 at 12:09:22PM +0200, Stefano Zacchiroli wrote:
  https://tracker.debian.org/teams/+create/
  
   I notice most teams from wiki.d.o/Teams/ are missing :/
  Up to each team if they want to use the tracker, few have chosen to do so.
 
 Yeah well, I suspect most teams simply don't know about this feature.

+1

I just created the Debian Med team.  What I did not is to add members to
the tracker.  IMHO it should be somehow doable to drain team members
from alioth rather than adding people to the a team twice (on alioth and
in tracker).

 
 AFAICT tracker.d.o as a whole (let aside the team feature) has not even
 been announced to d-d-a yet.  Maybe it's time to do that, highlighting
 specific opt-in features such as team claiming?

+1

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140916134540.gr4...@an3as.eu

Re: New package tracker - old one going?

[Andreas Tille]

Hi Iain,

On Tue, Sep 16, 2014 at 11:41:26AM +0100, Iain R. Learmonth wrote:
 
 If it still needs to be done the next time I find myself short of things to
 do, I will take a look.

Ahh, if you are again in this situation please tell me - I might have
some other thrilling tasks. ;-))
 
  Another option is to base your team thing on UDD.
  https://udd.debian.org/
 
 Did not know about this, this looks to be a useful source of information.

Uhmm, perhaps I did not mentioned it prominently enough in our Debian
Med sprint but all the Blends you might know from Debian Med and Debian
Games stuff is directly rendered from UDD.  Very nifty assemblage of
very valuable data.  If you are missing data there you can write a new
importer (been there, done that).

  BTW we already have several team things, could you just use those?
 
 I didn't know about these but I've had a look at them and they're not really
 what I'm looking for. I was thinking something similar to the blends web
 sentinels, but with a focus on being useful for end users too. Grouping the
 packages into categories for the functions they provide similar to the
 blends tasks so you can get an easy overview of all the packages in an
 area, and then contibutors can also see where areas are needing work.

So why not simply creating a Blend in the area you are considering?

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140916135046.gs4...@an3as.eu

Re: New package tracker - old one going?

[Andreas Tille]

Hi Iain,

On Tue, Sep 16, 2014 at 11:46:53AM +0100, Iain R. Learmonth wrote:
 On Tue, Sep 16, 2014 at 11:41:26AM +0100, Iain R. Learmonth wrote:
  I didn't know about these but I've had a look at them and they're not really
  what I'm looking for. I was thinking something similar to the blends web
  sentinels, but with a focus on being useful for end users too. Grouping the
  packages into categories for the functions they provide similar to the
  blends tasks so you can get an easy overview of all the packages in an
  area, and then contibutors can also see where areas are needing work.
 
 Saying this, if the ham radio team is willing to look into becoming a blend,
 then we would gain this anyway, and any missing features I was thinking of
 could be added to the blends web sentinel.

Considering Colin's answer you might be in the same situation as I was
two years ago facing that Debian Games would deserve the Blends stuff
but has not.  I created the needed framework when sitting inside the
Debian Games BoF at DebConf 11 in Banja Luka.  It remained untouched for
2.5 years.  Now Markus adopted it to something very useful.  So just
start doing something you might consider useful and if it really is
people will start using and enhancing it.  I'm really keen on seeing
what exactly you want to add to the Blends web sentinel to get this
available for all Blends!

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140916135520.gt4...@an3as.eu

Re: New package tracker - old one going?

[Iain R. Learmonth]

On Tue, Sep 16, 2014 at 03:50:46PM +0200, Andreas Tille wrote:
 So why not simply creating a Blend in the area you are considering?

This is now something being considered.

Iain.

-- 
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: +447875886930
c: MM6MVQ  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49


pgpk4_ZQexT8A.pgp
Description: PGP signature

Re: New package tracker - old one going?

[Andrew Shadura]

Hello,

On 16 September 2014 13:44, Raphael Hertzog hert...@debian.org wrote:
 - white background instead of gray one
 - more whitespace between panels
 - smaller font-size (this has already been reported in #756721

I personally dislike all of the three. Grey background adds some
contrast, little whitespace makes panels more compact so I don't need
to scroll the page while having bigger font size means I don't have
troubles reading the text.

So, basically, I'd like the new tracker to have the same stylesheet as
the old one. At least, make it an option (cookie-enabled, maybe?)

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACujMDM-2A2HnkQcM8FSXrwPb-=sntemtgocv6z4jwev-xs...@mail.gmail.com

Re: New package tracker - old one going?

[Raphael Hertzog]

On Tue, 16 Sep 2014, Scott Kitterman wrote:
 In mine, the top center panel being taken up by information about the
 new tracker makes it quite difficult to really get a feel for how
 readable/usable the new site is. Is there some way to make that
 removable? 

That panel is not displayed if you don't come from the old PTS. In
other words, start using the new tracker as reference and you won't
see that.

Just try it: http://tracker.debian.org/pkg/dpkg

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140916151212.gd12...@x230-buxy.home.ouaza.com

Re: New package doesn't fix the problem in the old version

[Raf Czlonka]

On Sat, Oct 08, 2011 at 04:50:35PM BST, Stefano Zacchiroli wrote:
 To nitpick a bit, your third possibility mentioned that the fix is not
 worth, but there are at least two sub-cases there: (1) maintainer does
 not want to spend *their own time* preparing the fix, but would gladly
 accept patches from others and (2) the maintainer does not want the fix
 to reach user machines (e.g. because they consider the fix might make
 things worse).

The fix is trivial and it won't make things worse.
Now probably not worth it but what could have been done in version 5-1:

if [ -f /etc/cron.d/git-repack-repositories ]
  then
sed -i 's/bin\/git-repack-repositories/bin\/git-repack-repositories-cron/g' 
\
/etc/cron.d/git-repack-repositories
fi

 Given Raf's interest in getting this particular issue fixed, I wonder
 whether he has tried proposing a patch to the maintainer (there is no
 trace of it in the buglog mentioned in this thread). Going that way can
 be way more useful in actually improving the life of users affected by
 the issue than this intriguing discussion about who *in theory* is
 responsible of cleaning up old debris.

No I hadn't as I've mentioned before, the fix is trivial and would have
taken me longer to do that than the maintainer, who already knows his
package and is dealing with debian packages on a daily basis, I on the
other hand hadn't created any packages in years.

 Share the code, we'll all be happier.

:^)

-- 
Raf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111011191058.GA20160@thor.local

Re: New package doesn't fix the problem in the old version

[Raf Czlonka]

Hi Ian,

Thanks for taking the time to reply.

   All I was trying to do was to establish was whether you're being
   lazy/unhelpful or is there a policy which I've missed as, [...]

I admit that I should have allowed a third possibility here.

 There is a third possibility which is that the maintainer has made a
 judgement that this bug is not worth going to special effort to fix in
 the package.  Policy does not need to be involved.

My point is exactly that: who makes the call?.
It's not just about that package and that particular bug.
Maybe there should be a clear policy, which should apply to all releases
which are fully fledged (stable, testing, unstable[0]), on what is
deemed to be called a bug fix - IMHO uninstall (purge rather) a package
and install it again is not.
Where should individual judgement end and a clear policy/good
practice/standard way of doing things, start?
If we scale it (might be a bit far-fetched, but it really isn't IMHO)
we get to the point where personal judgement and opinion takes
precedence over everything else and is quite harmful[1].

 The suggestion that someone is or might be lazy/unhelpful is not
 appropriate.

It should have read: lazy or unhelpful or ... but because of there
being two ORs I shortened it. As mentioned above I think I should have
included a possibility of a third one. This however doesn't change the
fact that lazy or unhelpful are some of many human states of mind,
and therefore I don't see it as inappropriate to enumerate them as one
is perfectly entitled to them. Besides, I gave it only as an option and
yes, should have included more to choose from.
I didn't mean any harm by it.

[0] experimental excluded for obvious reasons
[1] http://blog.aurel32.net/?p=47 - while the blog post itself is
valuable, the links included in there show exactly what I have in mind

Ta,
-- 
Raf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111008060729.GA7757@thor.local

Re: New package doesn't fix the problem in the old version

[Ian Jackson]

Raf Czlonka writes (Re: New package doesn't fix the problem in the old 
version):
 Hi Ian,
  There is a third possibility which is that the maintainer has made a
  judgement that this bug is not worth going to special effort to fix in
  the package.  Policy does not need to be involved.
 
 My point is exactly that: who makes the call?.

The maintainer(s) of the package(s) in question.  If you disagree and
care enough to escalate it, and you haven't managed to persuade the
maintainer, then debian-devel is available to give a second opinion
and if that's not sufficient for you, or doesn't reach consensus, the
Technical Committee is available to make a formal determination.

Note that when I say haven't managed to persuade the maintainer, I
don't mean that you harangued them in a bug report, by (for example)
implying they're lazy.  I mean that you had a reasonable and friendly
conversation where you make sure that the maintainer is aware of all
the relevant tradeoffs and consequences.  You need to conduct this
conversation in a manner that doesn't presuppose that the maintainer
has no option but to do as you wish.

 It's not just about that package and that particular bug.
 Maybe there should be a clear policy, which should apply to all releases
 which are fully fledged (stable, testing, unstable[0]), on what is
 deemed to be called a bug fix - IMHO uninstall (purge rather) a package
 and install it again is not.

No, there shouldn't.  Whether a transiently present bug needs special
action in current packages to fix it up, and how perfect that special
action needs to be, is not something we can or should write a single
simple policy for.  

It's a tradeoff, of precisely the kind that we delegate to
maintainers.

 If we scale it (might be a bit far-fetched, but it really isn't IMHO)
 we get to the point where personal judgement and opinion takes
 precedence over everything else and is quite harmful[1].

If a person makes a wrong judgement, we have mechanisms to deal with
that.  They may not be ideal, and I would like to see them improved,
but that doesn't mean that the right answer is to try to nail
everything down in policy.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20112.27211.999112.164...@chiark.greenend.org.uk

Re: New package doesn't fix the problem in the old version

[Stefano Zacchiroli]

On Sat, Oct 08, 2011 at 04:20:43PM +0100, Ian Jackson wrote:
 Raf Czlonka writes (Re: New package doesn't fix the problem in the old 
 version):
   There is a third possibility which is that the maintainer has made a
   judgement that this bug is not worth going to special effort to fix in
   the package.  Policy does not need to be involved.
  
  My point is exactly that: who makes the call?.
 
 The maintainer(s) of the package(s) in question.  If you disagree and
 care enough to escalate it, and you haven't managed to persuade the
 maintainer, then debian-devel is available to give a second opinion
 and if that's not sufficient for you, or doesn't reach consensus, the
 Technical Committee is available to make a formal determination.

To nitpick a bit, your third possibility mentioned that the fix is not
worth, but there are at least two sub-cases there: (1) maintainer does
not want to spend *their own time* preparing the fix, but would gladly
accept patches from others and (2) the maintainer does not want the fix
to reach user machines (e.g. because they consider the fix might make
things worse).

Given Raf's interest in getting this particular issue fixed, I wonder
whether he has tried proposing a patch to the maintainer (there is no
trace of it in the buglog mentioned in this thread). Going that way can
be way more useful in actually improving the life of users affected by
the issue than this intriguing discussion about who *in theory* is
responsible of cleaning up old debris.

Share the code, we'll all be happier.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: New package doesn't fix the problem in the old version

[Bernhard R. Link]

* Raf Czlonka rafal.czlo...@gmail.com [111007 17:17]:
 While the new package indeed does not contain the bug itself when
 installed as a new package on a system which hadn't had it before,
 it does not fix the bug if installed on a system with the older version.

As I had problems of understanding this first let me recap the
situation:

git-stuff before 5-1 created a buggy file when getting installed that
is still causing problems when git-stuff 7-1 is installed.

So it's not so much a bug in 7-1 but 7-1 not tidy up the mess left by
earlier versions.

As git-stuff was never released, those earlier buggy versions were
not released either, so only people installing unstable or testing
are effected.

For not too serious stuff in unstable it is usually widely accepted
that people sometimes might have to clean things up themselves.
(Any cleaning code means the package is bigger for everyone and
any fix could go wrong and introduce new bugs).

I'm not sure what the consensus for packages that were in testing
is (or if there was a consensus at all). I guess it mostly depends
on the time it was in testing and how complicated the fix is.

The bug was only in testing for either for 50 days or for 25 days,
so it might depend how complex the fix is.

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111007162603.gc4...@server.brlink.eu

Re: New package doesn't fix the problem in the old version

[Daniel Baumann]

the facts..

  * #640016 was introduced in version 2-1 on 2011-08-02.

  * #640016 was reported on 2011-09-01 and fixed on 2011-09-01 in
version 5-1.

  * version 4-1 with the bug migrated on 2011-08-23 to testing,
version 7-1 without the bug migrated on 2011-09-17 to testing.

  * testing was affected by the bug for 25 days.

  * the bug is by default not in the wild (git-repositories-repack
cronjob, priority low debconf question, defaults to no).

  * the bug is just that the wrongly called scripts fails by doing
nothing. worst case: user is annoyed by an error message that
nothing happened.

  * git-stuff was not yet part of a stable release.

my opinion..

  * everything that Bernhard already said.

  * adding preinst scripts that check for certain md5sums for files
sucks, in particular since in theory, you can only get rid of them
after stable+1. so not worth the hassle, in particulary not to
blow up the package considerably and unecessarily for everyone until
stable+1, just to mitigate a minor annoyance for a handful of
people.

  * unstable and *testing* users are supposed to be able to cope with
the one or other glitch, if they don't, they use stable.

  * this is a colossal waste of time.

Regards,
Daniel

--
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e8f323e.3030...@progress-technologies.net

Re: New package doesn't fix the problem in the old version

[Raf Czlonka]

On Fri, Oct 07, 2011 at 05:26:03PM BST, Bernhard R. Link wrote:
 As I had problems of understanding this first let me recap the
 situation:
 
 git-stuff before 5-1 created a buggy file when getting installed that
 is still causing problems when git-stuff 7-1 is installed.
 
 So it's not so much a bug in 7-1 but 7-1 not tidy up the mess left by
 earlier versions.

That's correct.

 As git-stuff was never released, those earlier buggy versions were
 not released either, so only people installing unstable or testing
 are effected.

 For not too serious stuff in unstable it is usually widely accepted
 that people sometimes might have to clean things up themselves.
 (Any cleaning code means the package is bigger for everyone and
 any fix could go wrong and introduce new bugs).

I've been using unstable exclusively for nearly 10 years.
Most if not all packages I reported bugs for DO fix the issues caused
by earlier versions, otherwise no one would use unstable if expected to
fix everything by hand.
I don't mind packages being broken, that's the reason why I use sid - to
help develop Debian, find and report bugs, etc.

 I'm not sure what the consensus for packages that were in testing
 is (or if there was a consensus at all). I guess it mostly depends
 on the time it was in testing and how complicated the fix is.
 
 The bug was only in testing for either for 50 days or for 25 days,
 so it might depend how complex the fix is.

It shouldn't matter that it's been in testing for so long, the bug's in
unstable, and should be fixed there, even if doesn't reach testing in a
long time.
Both the bug and a fix are trivial - it's simply an entry in a cron job
file - the links I've attached have all the relevant information.

Regards,
-- 
Raf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111007172312.GA28774@thor.local

Re: New package doesn't fix the problem in the old version

[Raf Czlonka]

On Fri, Oct 07, 2011 at 06:09:18PM BST, Daniel Baumann wrote:
 my opinion..
[cut]
   * unstable and *testing* users are supposed to be able to cope with
 the one or other glitch, if they don't, they use stable.

I know that, thank you. I've been doing that for nearly a decade.

   * this is a colossal waste of time.

That might be true.
All I was trying to do was to establish was whether you're being
lazy/unhelpful or is there a policy which I've missed as, per my earlier
email, I can't remember last time I filed a bug which later version
hadn't corrected, no matter how trivial it was.

Cheers,
-- 
Raf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111007174009.GA2944@thor.local