[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: X11 install experiences



On Sat, Mar 25, 2000 at 04:18:22AM +0000, Dale Scheetz wrote:
> > It's a judgement call.  Therefore I am exercising my judgement.
> > 
> Dependencies have clear specifications.

I agree:

"The Depends field should be used if the depended-on package is required
for the depending package to provide a significant amount of
functionality."

XF86Setup can provide almost all of its functionality when invoked from
within an already running X server.

I am willing to entertain the notion of making xf86setup recommend
xserver-vga16; "The Recommends field should list packages that would be
found together with this one in all but unusual installations."

In other words, I accept that many -- perhaps most -- people use XF86Setup
primarily to do initial configuration of the X server.  The relationship
clearly meets the criterion for a Recommends, and clearly does not for a
Depends.

In so far as there is any gray area here, it *is* within my discretion as
package maintainer to decide which way to the split the hair.

Since I have to do a 3.3.6-7 anyway, I will make xf86setup Recommend
xserver-vga16 specifically.

But a dependency is out of the question.

> > Also influencing my decision is the fact that, while XF86Setup is a nicer
> > looking program, xf86config actually does a better job of generating config
> > files.
> 
> Not when it inserts /dev/mouse for my specification of /dev/ttyS0.

XF86Setup does worse violence to XKB setups (I gather) for non-US/Candian
users.

It's far less easy to get XKB set up than the mouse.  Therefore, I think
xf86config's better chances of getting the Keyboard section right outweigh
its perhaps less than stellar handling of the Mouse section.

N.B., however that I don't have a bug report or a method of reproducing
this xf86config mouse problem.  So officially, all I have is your word that
you didn't do something stupid. :)

> And just what is it? The following has nothing to do with keeping the
> VGA16 server off machines that don't need it for a re-configure. If you
> include it in common then it gets installed.

I already told you I would do this, and I'm furthermore throwing the bone
of a Recommends.  I'm not inclined to go further that this because I think
it is 1) objectively wrong to do so given the definitions in the packaging
manual and 2) the level of harassment I'm getting from you on the issue.

> > For one thing, XF86Setup does not "depend" on the VGA16
> > server specifically, using the packaging manual's definition of "depend".
> > 
> It refuses to run unless the vga16 server is installed! I'd call that a
> strict definition of depends!

This is patently false.

I just now ran XF86Setup from an xterm.

> It refuses to run even when there is another
> server installed and that server is set as the default. I can only assume
> that it _will_ run if I have a config file. Seems the easier thing to do
> is make an initial install into a re-configure by providing a "default"
> XF86Config file and "modifying" it to suit the new install.

What?  There's no way I can ship an XF86Config file that will work for even
a majority of situations.  If I could, there'd be far less need fot
XF86Config file generation tools.  Chicken and egg.

> You seem focused on the act of using this "setup" program to re-configure
> a server, which is very nice, but not the principle use as described by
> the package name. This program _is_ expected to work under setup
> conditions.

And it does.

> > Furthermore, users can no longer really use --force-depends with dpkg
> > anymore.  apt will complain and refuse to function.
> 
> Great! Just what I need, less control over my system ;-(

Well, I find that situation less than optimal as well, but you'll have to
talk to Jason Gunthorpe about it.

-- 
G. Branden Robinson            |   <joeyh> oh my, it's a UP P III.
Debian GNU/Linux               |   <doogie> dos it.
branden@ecn.purdue.edu         |   * joeyh runs dselect
roger.ecn.purdue.edu/~branden/ |   <Overfiend> that ought to be sufficient :)

Attachment: pgprOCFkniYJW.pgp
Description: PGP signature


Reply to: