Create a -cli package without a different executable

[Fabien Nicoleau]

Hi,

I'm packaging phatch that provides /usr/bin/phatch, a graphical
application to manage some operations on photos. It handles command
line parameters so that it can be used in a script, without a GUI :
if no parameters are given, a GUI is displayed, otherwise it acts as a
console application.

Upstream asked me if it's possible to keep "phatch" package, containing
the graphical requirements (and requires) and requires phatch-cli, and
create a phatch-cli, that provides /usr/bin/phatch. With this way,
people could just install phatch-cli on a server and use it with
command line parameters (but it would crash if it's not launched with
parameters).

My question is :
is it good to provide a -cli package that does not provides a separate
script or executable file, and that will work only if the user is
carefull to not launch it in a way that it does not require a graphic
lib (without parameters in that context) ?

Regards,

Fabien NICOLEAU

[Susi Lehtola]

On Fri, 2009-12-18 at 18:12 +0100, Nicoleau Fabien wrote:
> My question is :
> is it good to provide a -cli package that does not provides a separate
> script or executable file, and that will work only if the user is
> carefull to not launch it in a way that it does not require a graphic
> lib (without parameters in that context) ?

The design seems idiotic.

Anyway, you have to weigh the surplus of admins not having to install
graphical stuff on their servers versus the possible problems caused by
new users trying to work the package in a way it isn't supposed to be
used.

I'd say: it's up to the packager.

[Jon Ciesla]

Jussi Lehtola wrote:
> On Fri, 2009-12-18 at 18:12 +0100, Nicoleau Fabien wrote:
> > My question is :
> > is it good to provide a -cli package that does not provides a separate
> > script or executable file, and that will work only if the user is
> > carefull to not launch it in a way that it does not require a graphic
> > lib (without parameters in that context) ?
>
> The design seems idiotic.
>
> Anyway, you have to weigh the surplus of admins not having to install
> graphical stuff on their servers versus the possible problems caused by
> new users trying to work the package in a way it isn't supposed to be
> used.
>
> I'd say: it's up to the packager.

Or, package it , er, twice, with two copies with different options.  
See: Ettercap

Warning:  This is the most annoying choice, and I sometimes regret it.

-J

[Julian Aloofi]

Am Freitag, den 18.12.2009, 18:12 +0100 schrieb Nicoleau Fabien:
> Hi,
>
> I'm packaging phatch that provides /usr/bin/phatch, a graphical
> application to manage some operations on photos. It handles command
> line parameters so that it can be used in a script, without a GUI :
> if no parameters are given, a GUI is displayed, otherwise it acts as a
> console application.
>
> Upstream asked me if it's possible to keep "phatch" package, containing
> the graphical requirements (and requires) and requires phatch-cli, and
> create a phatch-cli, that provides /usr/bin/phatch. With this way,
> people could just install phatch-cli on a server and use it with
> command line parameters (but it would crash if it's not launched with
> parameters).
>
> My question is :
> is it good to provide a -cli package that does not provides a separate
> script or executable file, and that will work only if the user is
> carefull to not launch it in a way that it does not require a graphic
> lib (without parameters in that context) ?
>
> Regards,
>
> Fabien NICOLEAU

I see phatch is a python package, so I think a little trick could be
possible:

%package cli:
BuildRequires:	python-devel
Requires:	non-gui-dependencies
%files
{_bindir}/phatch

and for the main package:
Requires:	phatch-cli
Requires:	pygtk2, <gui-dependencies>
[install desktop file etc...]

This way users could explicitly install phatch-cli, and it would "only"
not start up properly if called without arguments on a terminal, and the
main package (gui version) would contain the program and pull in the
graphical dependencies.
I don't know the program though, and if the cli version depends on gui
libraries to work properly as well it wouldn't work.

[Fabien Nicoleau]

Le Fri, 18 Dec 2009 22:39:18 +0100,
Julian Aloofi  a écrit :
> Am Freitag, den 18.12.2009, 18:12 +0100 schrieb Nicoleau Fabien:
> > Hi,
> >
> > I'm packaging phatch that provides /usr/bin/phatch, a graphical
> > application to manage some operations on photos. It handles command
> > line parameters so that it can be used in a script, without a GUI :
> > if no parameters are given, a GUI is displayed, otherwise it acts
> > as a console application.
> >
> > Upstream asked me if it's possible to keep "phatch" package,
> > containing the graphical requirements (and requires) and requires
> > phatch-cli, and create a phatch-cli, that provides /usr/bin/phatch.
> > With this way, people could just install phatch-cli on a server and
> > use it with command line parameters (but it would crash if it's not
> > launched with parameters).
> >
> > My question is :
> > is it good to provide a -cli package that does not provides a
> > separate script or executable file, and that will work only if the
> > user is carefull to not launch it in a way that it does not require
> > a graphic lib (without parameters in that context) ?
> >
> > Regards,
> >
> > Fabien NICOLEAU
>
> I see phatch is a python package, so I think a little trick could be
> possible:
>
> %package cli:
> BuildRequires:	python-devel
> Requires:	non-gui-dependencies
> %files
> {_bindir}/phatch
>
> and for the main package:
> Requires:	phatch-cli
> Requires:	pygtk2, <gui-dependencies>
> [install desktop file etc...]
>
> This way users could explicitly install phatch-cli, and it would
> "only" not start up properly if called without arguments on a
> terminal, and the main package (gui version) would contain the
> program and pull in the graphical dependencies.
> I don't know the program though, and if the cli version depends on gui
> libraries to work properly as well it wouldn't work.

Yes, I'll probably use this way :)

thx

[Toshio Kuratomi]

On Fri, Dec 18, 2009 at 10:39:18PM +0100, Julian Aloofi wrote:
> Am Freitag, den 18.12.2009, 18:12 +0100 schrieb Nicoleau Fabien:
> > Hi,
> >
> > I'm packaging phatch that provides /usr/bin/phatch, a graphical
> > application to manage some operations on photos. It handles command
> > line parameters so that it can be used in a script, without a GUI :
> > if no parameters are given, a GUI is displayed, otherwise it acts as a
> > console application.
> >
> > Upstream asked me if it's possible to keep "phatch" package, containing
> > the graphical requirements (and requires) and requires phatch-cli, and
> > create a phatch-cli, that provides /usr/bin/phatch. With this way,
> > people could just install phatch-cli on a server and use it with
> > command line parameters (but it would crash if it's not launched with
> > parameters).
> >
> > My question is :
> > is it good to provide a -cli package that does not provides a separate
> > script or executable file, and that will work only if the user is
> > carefull to not launch it in a way that it does not require a graphic
> > lib (without parameters in that context) ?

Sounds like the goal is good but the implementation is not.
> >
>
> I see phatch is a python package, so I think a little trick could be
> possible:
>
> %package cli:
> BuildRequires:	python-devel
> Requires:	non-gui-dependencies
> %files
> {_bindir}/phatch
>
> and for the main package:
> Requires:	phatch-cli
> Requires:	pygtk2, <gui-dependencies>
> [install desktop file etc...]
>
> This way users could explicitly install phatch-cli, and it would "only"
> not start up properly if called without arguments on a terminal, and the
> main package (gui version) would contain the program and pull in the
> graphical dependencies.
> I don't know the program though, and if the cli version depends on gui
> libraries to work properly as well it wouldn't work.

This is not ideal but it needs some coding to come up with something better.
Possibilities:

* phatch with no options can attempt to import a gui lib.  If that
  succeeds it launches the graphical interface.  If it does not succeed, it
  displays the usage/help message.
* phatch is a command line app.  When invoked as gphatch it starts as
  a gui app instead.  The phatch-gui subpackage installs a symlink from
  /usr/bin/gpatch to /usr/bin/phatch as well as .desktop files.

Basically, it's great to have the option to get the functionality of the
program without having to install the GUI environment.  But the program
tracebacking when the GUI environment is not present and the user typed the
command name without options is not good behaviour for a program.

-Toshio

[Fabien Nicoleau]

Le Sat, 19 Dec 2009 22:08:45 -0800,
Toshio Kuratomi  a écrit :
> On Fri, Dec 18, 2009 at 10:39:18PM +0100, Julian Aloofi wrote:
> > Am Freitag, den 18.12.2009, 18:12 +0100 schrieb Nicoleau Fabien:
> > > Hi,
> > >
> > > I'm packaging phatch that provides /usr/bin/phatch, a graphical
> > > application to manage some operations on photos. It handles
> > > command line parameters so that it can be used in a script,
> > > without a GUI : if no parameters are given, a GUI is displayed,
> > > otherwise it acts as a console application.
> > >
> > > Upstream asked me if it's possible to keep "phatch" package,
> > > containing the graphical requirements (and requires) and requires
> > > phatch-cli, and create a phatch-cli, that
> > > provides /usr/bin/phatch. With this way, people could just
> > > install phatch-cli on a server and use it with command line
> > > parameters (but it would crash if it's not launched with
> > > parameters).
> > >
> > > My question is :
> > > is it good to provide a -cli package that does not provides a
> > > separate script or executable file, and that will work only if
> > > the user is carefull to not launch it in a way that it does not
> > > require a graphic lib (without parameters in that context) ?
>
> Sounds like the goal is good but the implementation is not.
> > >
> >
> > I see phatch is a python package, so I think a little trick could be
> > possible:
> >
> > %package cli:
> > BuildRequires:	python-devel
> > Requires:	non-gui-dependencies
> > %files
> > {_bindir}/phatch
> >
> > and for the main package:
> > Requires:	phatch-cli
> > Requires:	pygtk2, <gui-dependencies>
> > [install desktop file etc...]
> >
> > This way users could explicitly install phatch-cli, and it would
> > "only" not start up properly if called without arguments on a
> > terminal, and the main package (gui version) would contain the
> > program and pull in the graphical dependencies.
> > I don't know the program though, and if the cli version depends on
> > gui libraries to work properly as well it wouldn't work.
>
> This is not ideal but it needs some coding to come up with something
> better. Possibilities:
> phatch with no options can attempt to import a gui lib.  If that
> succeeds it launches the graphical interface.  If it does not
>
> succeed, it displays the usage/help message.
> phatch is a command line app.  When invoked as gphatch it starts as
> a gui app instead.  The phatch-gui subpackage installs a symlink
>
> from /usr/bin/gpatch to /usr/bin/phatch as well as .desktop files.
>
> Basically, it's great to have the option to get the functionality of
> the program without having to install the GUI environment.  But the
> program tracebacking when the GUI environment is not present and the
> user typed the command name without options is not good behaviour for
> a program.
>
> -Toshio

In fact I was wrong about the fact that phatch will crash if it's
called with no params (so as the gui version). A message is displayed
and tells and explain that the user has to install 'phatch' (containing
gui stuff).

So its seems pretty clean to me, and easy to manage.

Fabien Nicoleau