On Tue, Jul 08, 2014 at 03:57:20PM -0400, Eric Cooper wrote:
> On Wed, Jul 09, 2014 at 06:57:02AM +1200, Chris Bannister wrote:
> > On Tue, Jul 08, 2014 at 11:31:12AM -0400, Eric Cooper wrote:
> > > Since Debian package names must already be unique, we ought to be able
> > > to leverage that to avo
On Wed, Jul 09, 2014 at 06:57:02AM +1200, Chris Bannister wrote:
> On Tue, Jul 08, 2014 at 11:31:12AM -0400, Eric Cooper wrote:
> > Since Debian package names must already be unique, we ought to be able
> > to leverage that to avoid having to fight over which package gets to
> > claim which binary
On Tue, Jul 08, 2014 at 11:31:12AM -0400, Eric Cooper wrote:
> Since Debian package names must already be unique, we ought to be able
> to leverage that to avoid having to fight over which package gets to
> claim which binary name.
>
> What about making it into a user's install-time decision,
> ra
Le mardi 08 juillet 2014 à 11:31 -0400, Eric Cooper a écrit :
> Since Debian package names must already be unique, we ought to be able
> to leverage that to avoid having to fight over which package gets to
> claim which binary name.
>
> What about making it into a user's install-time decision,
>
Le mardi 08 juillet 2014 à 09:04 -0700, Don Armstrong a écrit :
> On Tue, 08 Jul 2014, Eric Cooper wrote:
> > What about making it into a user's install-time decision, rather than
> > a developer's packaging-time decision?
>
> Any user who wants to can override the rename by using dpkg-divert.
Bu
On Tue, 08 Jul 2014, Eric Cooper wrote:
> What about making it into a user's install-time decision, rather than
> a developer's packaging-time decision?
Any user who wants to can override the rename by using dpkg-divert.
--
Don Armstrong http://www.donarmstrong.com
We were
Since Debian package names must already be unique, we ought to be able
to leverage that to avoid having to fight over which package gets to
claim which binary name.
What about making it into a user's install-time decision,
rather than a developer's packaging-time decision?
As a proof of concept,
On Mon, Jul 07, 2014 at 11:12:23PM -0700, Vincent Cheng wrote:
> On Mon, Jul 7, 2014 at 9:48 AM, costamagnagianfra...@yahoo.it
> wrote:
> >
> > Hi Steffen and all,
> >
> > today while talking with a backbox project administrator I discovered that
> > popular tools such as openvas directly calls th
Charles Plessy writes:
> Here the surprise would come only if there were a system that is set
> up for both the purpose of bioinformatics and security port scanning,
> without the users being aware that there can be one or the other
> alternative installed. I think that it is very unlikely.
I th
Hi Charles,
Quoting Charles Plessy (2014-07-08 13:24:34)
> We also have to consider that large multi-user, multi-purpose systems
> are becoming rare because it is easier to have virtual servers,
> chroots, and other container solutions. To the practical possibility
> of needing both programs a
Hi Charles,
Charles Plessy wrote:
> Here, both programs have narrow and non-overlaping user bases, and are
> not installed on fresh standard Debian systems.
>
> This said, you made a good point that one has to consider if programs
> can be accidentally called with root priviledges, and what wil
Hi Lars,
thanks for your well-argumented and detailed position on this subject. The
problems that you describe can be roughly summarised by “principle of least
surprise” and “slippery slope”. In this particular case, I quite disagree with
the first, but of course can not entirely dismiss the sec
On Mon, Jul 7, 2014 at 9:48 AM, costamagnagianfra...@yahoo.it
wrote:
>
> Hi Steffen and all,
>
> today while talking with a backbox project administrator I discovered that
> popular tools such as openvas directly calls the amap binary.
>
> I never talked with them, but I don't think it is feasibl
Hi Steffen and all,
today while talking with a backbox project administrator I discovered that
popular tools such as openvas directly calls the amap binary.
I never talked with them, but I don't think it is feasible to ask to every
security tool provider to patch their code for the only debian
On Mon, 7 Jul 2014, Adam Borowski wrote:
By the way, it would be nice to have a common scheme for installing wrappers
of this kind -- especially if /bin vs /usr/bin is going to go away.
If you're open to dpkg-divert, config-package-dev lets you do this. Taking
molly-guard as an example, insta
On Mon, Jul 07, 2014 at 12:19:15AM +0200, Jakub Wilk wrote:
> * Adam Borowski , 2014-07-06, 21:04:
> >I see some legitimate scenarios for a single package to have
> >something both in $X/bin and $X/sbin, but not really across
> >package boundaries.
>
> These are deliberate:
None of your examples
On Jul 07, Jakub Wilk wrote:
> Would you call them “legitimate” or not?
I would call them "a future problem" since the world is moving to using
/usr/bin/ for everything and I expect that we will follow as well in
a couple of releases.
--
ciao,
Marco
signature.asc
Description: Digital signat
* Adam Borowski , 2014-07-06, 21:04:
I see some legitimate scenarios for a single package to have something
both in $X/bin and $X/sbin, but not really across package boundaries.
These are deliberate:
* safe-rm ships /usr/bin/rm;
* molly-guard ships /usr/sbin/{halt,poweroff,reboot,shutdown}
*
Hi!
On Sun, 2014-07-06 at 21:04:25 +0200, Adam Borowski wrote:
> On Sun, Jul 06, 2014 at 04:02:05PM +0100, Lars Wirzenius wrote:
> > The standards FHS directory layout gives us four locations in which to
> > put executabes: /bin, /sbin, /usr/bin, /usr/sbin. In theory we could
> > then have four pr
On Sun, Jul 06, 2014 at 04:02:05PM +0100, Lars Wirzenius wrote:
> The standards FHS directory layout gives us four locations in which to
> put executabes: /bin, /sbin, /usr/bin, /usr/sbin. In theory we could
> then have four providers of yoyo, but that would be very confusing.
> Even using bin vs s
On Sun, Jul 06, 2014 at 10:49:30PM +0900, Charles Plessy wrote:
> Le Sun, Jul 06, 2014 at 10:33:35AM +0200, Andreas Tille a écrit :
> > On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:
> > > >
> > > > This violates the Policy's section 10.1, but it is still my
> > > > favorite solutio
> Il Domenica 6 Luglio 2014 15:51, Charles Plessy ha
> scritto:
> > Le Sun, Jul 06, 2014 at 10:33:35AM +0200, Andreas Tille a écrit :
>
>> On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:
>> > >
>> > > This violates the Policy's section 10.1, but it is still my
> favorite s
Le Sun, Jul 06, 2014 at 10:33:35AM +0200, Andreas Tille a écrit :
> On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:
> > >
> > > This violates the Policy's section 10.1, but it is still my favorite
> > > solution
> > > for the reason that you explained above.
> >
> > I don't agree,
Hi Javier,
thanks for your hint!
That was my first thoght, I'm upstream developer and DM of ettercap and we
already install in sbin some of the binaries.
The problem is:
what does it happen when the user have both amap installed on the system and
runs "amap" from the bash?
This might be highl
❦ 6 juillet 2014 10:56 +0200, Javier Fernandez-Sanguino :
> Since 'amap' (the scanner) probably needs permission to make raw
> sockets to work properly (just like nmap) for some scans, why not
> install it in /usr/sbin/? That way there would be no conflict with the
> other package.
This has al
El 05/07/2014 16:47, "Ralf Treinen" escribió:
>
> On Sat, Jul 05, 2014 at 09:01:45PM +0900, Charles Plessy wrote:
> > > > Il Sabato 5 Luglio 2014 13:03, Charles Plessy
ha scritto:
> > > >
> > > > The ‘amap-align’ package version 2.2-4 install the file ‘amap’ in
‘/usr/bin’,
> > > > this is why I a
On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:
> >
> > This violates the Policy's section 10.1, but it is still my favorite
> > solution
> > for the reason that you explained above.
>
> I don't agree, packages should not be in conflict when it can be easily
> avoided
> by renamin
On Sat, Jul 05, 2014 at 09:01:45PM +0900, Charles Plessy wrote:
> > > Il Sabato 5 Luglio 2014 13:03, Charles Plessy ha
> > > scritto:
> > >
> > > The ‘amap-align’ package version 2.2-4 install the file ‘amap’ in
> > > ‘/usr/bin’,
> > > this is why I am worried about clashes.
>
> Le Sat, Jul 05
> Il Sabato 5 Luglio 2014 14:03, Charles Plessy ha scritto:
> >> > Il Sabato 5 Luglio 2014 13:03, Charles Plessy
> ha scritto:
>> >
>> > The ‘amap-align’ package version 2.2-4 install the file ‘amap’ in
> ‘/usr/bin’,
>> > this is why I am worried about clashes.
>
> Le Sat, Jul 05, 2014
> > Il Sabato 5 Luglio 2014 13:03, Charles Plessy ha
> > scritto:
> >
> > The ‘amap-align’ package version 2.2-4 install the file ‘amap’ in
> > ‘/usr/bin’,
> > this is why I am worried about clashes.
Le Sat, Jul 05, 2014 at 12:11:37PM +0100, Gianfranco Costamagna a écrit :
>
> According to bo
Hi Charles
> Il Sabato 5 Luglio 2014 13:03, Charles Plessy ha scritto:
> > Le Sat, Jul 05, 2014 at 11:56:28AM +0100, Gianfranco Costamagna a écrit :
>>
>> I looked before at amap-align, but the package provided by your one is only
>> amap-align, there is no "amap" installable, hence I don't
Hi Clarles,
> Il Sabato 5 Luglio 2014 12:48, Charles Plessy ha scritto:
> > Le Fri, Jul 04, 2014 at 02:20:12PM +0100, Gianfranco Costamagna a écrit :
>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Gianfranco Costamagna
>>
>> * Package name : amap
>> Version : 5.4
>>
Le Sat, Jul 05, 2014 at 11:56:28AM +0100, Gianfranco Costamagna a écrit :
>
> I looked before at amap-align, but the package provided by your one is only
> amap-align, there is no "amap" installable, hence I don't think there will be
> a clash for the packages, right?
The ‘amap-align’ package ver
Le Fri, Jul 04, 2014 at 02:20:12PM +0100, Gianfranco Costamagna a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Gianfranco Costamagna
>
> * Package name : amap
> Version : 5.4
> Upstream Author : Van Hauser
> * URL : http://www.thc.org/thc-amap/
> * License
Package: wnpp
Severity: wishlist
Owner: Gianfranco Costamagna
* Package name : amap
Version : 5.4
Upstream Author : Van Hauser
* URL : http://www.thc.org/thc-amap/
* License : GPL-2+
Programming Lang: C
Description : Next-generation scanning tool for pe
35 matches
Mail list logo
