Dear Maintainer,

I installed minimal Debian system from netinst iso.
Then, I installed Xorg this way:
apt-get install --no-install-recommends xserver-xorg xinit xterm

Now, I would like to install x11-xserver-utils. This package is 160 KB big.
But when I try
apt-get install --no-install-recommends x11-xserver-utils
it wants to install 27 MB of data. This is WRONG.

It reports that the package needs to download and install (among others)
these additional packages: cpp cpp-6 libisl15

I do not see why to install cpp. This is WRONG.

I expect you to drop cpp dependencies because it should not be there.
Maybe move it to *recommends*, but no reason to require it.

Thank you for fixing this.

At 2017-10-15T07:06:15-0400, Tomas Matejicek wrote:

Your tone is pretty strident coming from someone who's flatly incorrect.

x11-xserver-utils depends on cpp because the xrdb program invokes the C
preprocessor.

See the "-cpp" and "-nocpp" options of the xrdb(1) manual page for
further information.

[X Strike Force: My new key still isn't in the maintainer keyring as far
as I know, so I will refrain from closing this bug.  I recommend that
it be closed as invalid.]

Regards,
Branden

Hi.
Please ignore my tone, I have troubles writing english.

I didn't know about cpp or nocpp options.
Nevertheless, xrdb works for me even without cpp. It is probably
because I do not need it to preprocess anything.

Man page states:
The file specified by filename ... is *optionally* passed through the
C preprocessor.

My understanding is that preprocessing is optional.
And only useful if user needs it. Am I correct?

I do not know what are debian policies for requiring a dependency.

But I still believe that requiring 27MB of something for a 160KB
package is not optimal.

Is there any way to exclude cpp from required dependencies? Is there
any way to make it optional? Suggested? Or I don't know :-)

Thanks

Tomas M

At 2017-10-15T19:54:06+0200, Tomas M wrote:

No worries.  I'm pretty close to monolingual so it is difficult for me
to express myself in _any_ tone in another language.

Possibly.  If you don't use any X clients using the Athena widget set,
it's possible you're not noticing that you don't get them in color; see
/etc/X11/Xresources/x11-common.

I looked over the source code and while use of a preprocessor is
optional, it is also the default.  So Debian is kind of stuck with it.

It is the default, and can be disabled by the user if the user knows how
to do so.

The Debian Policy Manual is thick but generally we support enabling as
many features as possible in service of being a "universal operating
system".

I agree that it can take one aback.  But some pretty small executable
programs require the pretty big C library.

I don't think dropping the dependency or switching preprocessing off for
Debian's xrdb is advisable because to do will break the expectations of
existing users and very long-standing practice.

Splitting xrdb off into its own package is a possibility, if and when
"legacy-free" X environments become common.  I have no data on how close
we are to that point, and it certainly doesn't describe my system.
While I run GNOME, I also use xterm as my preferred terminal
emulator--it's simply the best emulator of terminals--and it is a very
traditional resource-using, Xt/Xaw-based X client.

Another alternative would be to locate or write, and package if
necessary, a "light" C-compatible C preprocessor[1] that can do
everything xrdb requires of it.  xrdb(1) says that the only features
required are file inclusion, symbol definition, and symbol
un-definition.  In practice, users expect #ifdef..#else..#endif as well,
and according to the source code, when running the "default" cpp, it
also passes the -P to cpp.  cpp's usage message does not document this,
but it's in the Texinfo manual[2]:

***
-P

    Inhibit generation of linemarkers in the output from the
preprocessor. This might be useful when running the preprocessor on
something that is not C code, and will be sent to a program which might
be confused by the linemarkers.
***

Another practical obstacle is that no subset of the C preprocessor
language consistent with long-standing practice is defined.  Xlib's
documentation on resource management says:

The syntax of a resource file is a sequence of resource lines terminated
by newline characters or the end of the file. The syntax of an
individual resource line is:

***
ResourceLine	=	Comment | IncludeFile | ResourceSpec | <empty line>
Comment		=	"!" {<any character except null or newline>}
IncludeFile	=	"#" WhiteSpace "include" WhiteSpace FileName WhiteSpace
FileName	=	<valid filename for operating system>
ResourceSpec	=	WhiteSpace ResourceName WhiteSpace ":" WhiteSpace Value
ResourceName	=	[Binding] {Component Binding} ComponentName
Binding		=	"." | "*"
WhiteSpace	=	{<space> | <horizontal tab>}
Component	=	"?" | ComponentName
ComponentName	=	NameChar {NameChar}
NameChar	=	"a"-"z" | "A"-"Z" | "0"-"9" | "_" | "-"
Value		=	{<any character except null or unescaped newline>}
***

...which does not permit the use of "#ifdef" clauses and would make the
xrdb man page's demand for support for the -D and -U flags pointless if
that exclusion were actually enforced.  (Well, not really.  It would
still be useful for macro substitution but I can't remember the last
time I saw an X resource file that actually _used_ that feature.)

In practice, use of xrdb in the real world has not been conservative
about what it expects from the C preprocessor, with the result that it's
difficult to say how "light" a stripped-down cpp for xrdb needs to be.
Real cpps need to be able to evaluate a fair amount of C language
syntax.

Are you up to the challenge?

[1] cccp, with the foregoing expanded name, was in fact the name for GNU
cpp when it was installed as a non-vendor compiler on old Unix systems.

[2] Whoops. I've quoted an FDL manual. Now I am legally bound to
reproduce the entire license per its terms.  See attachment.

Regards,
Branden

Thanks for the explanation.

I want to use xrdb for one purpose only: to configure xterm by using
.Xresources file (so using -merge option of xrdb).

I tried strace on xrdb and I noticed that it indeed calls cpp, and if
that is not installed, it simply works without it (probably skipping
preprocessing, I don't know, since I don't use ifdefs).

If the cpp is configured in the package as 'recommended' (not
required), it will be installed by "apt-get install x11-xserver-utils"
for all users anyway, right? So only those users who decide to use
--no-install-recommends will not install cpp. Is this not a
possibility? This would keep cpp installed for all people as before,
while it would enable users to exclude it when they know they do not
need it. What do you think?

Tomas M

At 2017-10-16T08:35:09+0200, Tomas M wrote:

Yup, that's pretty much the only mileage I get out of it as well.  For
many years I had to fiddle some Xft knobs but no longer; those are
commented out, maybe since Jessie.

For your edification, it might be worth seeing what gets open()ed if cpp
_is_ installed and you follow child processes (strace -f).

That certainly sounds like a possibility to me.  It wouldn't personally
break my work habits because I follow the default of installing
Recommended packages automatically, and a desktop without a toolchain is
an unthinkable concept to me, so I always have cpp (and much else)
installed anyway.

Demoting cpp to a Recommends sounds pretty close to the optimum in the
effort-benefit space.  IMO.  At least it's worth a trial run in unstable
to see how many users squawk that all the colors in their Athena apps
have gone away.  (We might be doing them a favor; some of the resource
defaults for widget colors in some Athena apps are textbooks cases of
the 'Angry Fruit Salad' UI.)

Regards,
Branden

[Footnote] The original X guys just _loved_ cpp.  They not only stacked
their user-preference-management system on top of it, they based their
entire build configuration system on it--it was called imake, and in
hindsight is widely regarded as a Bad Idea.  In fact, I think we
(Debian) only recently stopped shipping it.

Yeah, I agree too :)

Since you received this bug report, you are the maintainer of the
package, right?
So, you are the best person to do that. Will you please do it now?

Thank you!


Tomas M

At 2017-10-17T07:37:50+0200, Tomas M wrote:

Hasty conclusion.  The X packages are team-maintained, and bugs against
them go to a mailing list, debian-x.  I am subscribed to that list.

I also have something of a history maintaining X for Debian, but I
have not been closely involved for several years.

Sorry, that's up to those who actually do the work, and according to the
package changelog for x11-xserver-utils, that's been Julien Cristau for
this package for the past 6+ years.

I'm currently waiting for DAM to merge my new GPG key into the
maintainer keyring.  Once that is done I may be able to help out with
things like this.

And even if I were fully enabled to do an upload, I'd like to hear the
views of Julien and others on this list before making a change that
will regress functionality for some subset of users.  (Perhaps the size
of that subset is zero; that sort of information is valuable.)