Re: patch 004 is overkill

2004-01-15 Thread Branden Robinson
On Wed, Jan 14, 2004 at 06:10:51PM -0600, Warren Turkal wrote:
 Branden Robinson wrote:
 
  That too.  :)  I also wanted to make it possible to reference any
  manual section from within a manual page without hard-coding the section
  numbers.
 
 You wanted the section not to be dependent on the suffix? Is that correct?

No, I mean that I want manpages to be able to say:

.SH SEE ALSO
X(__mansuffix__), sbrk(__ossyscallmansuffix__),
malloc(__oslibmansuffix__), mouse(__osdrivermansuffix__),
mouse(__drivermansuffix__), hosts(__osfilemansuffix__),
fortune(__osgamemansuffix__),

...and so forth.

  Because I never submitted them.
 
 May I submit them. I doubt DD will accept them, but I would like to try.

Sure.  You may want to improve the description of the patch now that I
have bothered to explain it.  :)

  If you need imake, you B-D on the package that contains it.
  
  $ dpkg -S bin/imake
  xutils: /usr/X11R6/bin/imake
 
 I figured that out after the message. Oops :-)

:)

  $ % grep-dctrl -F Build-Depends,Build-Depends-Indep -s Package xutils
  /var/lib/apt/lists/http.us.debian.org_debian_dists_unstable_main_source_Sources
  |wc -l 271
 
  Perhaps not all of those build-depend on imake (there are other things
  in xutils), but I'll bet you most of them do.
 
 Maybe imake should be split into its own package so that this can be more
 easily tracked?

I don't think that is sufficient reason to split a package.  XFree86
already produces a dizzying number of binary packages.  I'm open to
other arguments why splitting imake might be a good idea, though.

  I disagree with your premise and your conclusion.
 
 That is probably more sane than me :-). I was trying to make patches smaller
 for the 4.4 cycle. Thanks for discussing this with me.

Making patches smaller/more sane/etc. is good and valuable work, and I
appreciate your efforts to make the 4.4 cycle less user-angering than
4.3's has been.  However, we must take care not to throw out the baby with
the bathwater.  :)

-- 
G. Branden Robinson|Men use thought only to justify
Debian GNU/Linux   |their wrong doings, and speech only
[EMAIL PROTECTED] |to conceal their thoughts.
http://people.debian.org/~branden/ |-- Voltaire


signature.asc
Description: Digital signature


Re: patch 004 is overkill

2004-01-15 Thread Warren Turkal
Branden Robinson wrote:

 Making patches smaller/more sane/etc. is good and valuable work, and I
 appreciate your efforts to make the 4.4 cycle less user-angering than
 4.3's has been.  However, we must take care not to throw out the baby with
 the bathwater.  :)

I heard that.

wt
-- 
Warren Turkal
President, GOLUM, Inc.
http://www.golum.org



Re: patch 004 is overkill

2004-01-14 Thread Warren Turkal
Branden Robinson wrote:

 You appear to be overlooking some of the purpose of my patch.  Consider
 the phenomenon of a game with a manpage, which uses imake as its build
 system.

I guess I was mistaken. I thought that this patch was just trying to get the
manpages in the right places. Are the new defines that you make (eg
GameManSection) de facto standards anywhere other than in XF86 in Debian.
If so, why are these modifications not included upstream?

I cannot find anything in the Debian archive the even build depends on
imake. Maybe we should prune some of the unused macros.

wt
-- 
Warren Turkal
President, GOLUM, Inc.
http://www.golum.org



Re: patch 004 is overkill

2004-01-14 Thread Branden Robinson
On Wed, Jan 14, 2004 at 02:42:33AM -0600, Warren Turkal wrote:
 Branden Robinson wrote:
 
  You appear to be overlooking some of the purpose of my patch.  Consider
  the phenomenon of a game with a manpage, which uses imake as its build
  system.
 
 I guess I was mistaken. I thought that this patch was just trying to get the
 manpages in the right places.

That too.  :)  I also wanted to make it possible to reference any
manual section from within a manual page without hard-coding the section
numbers.

 Are the new defines that you make (eg GameManSection) de facto
 standards anywhere other than in XF86 in Debian.

Yes, but I don't remember where.  I'll pathetically defer to Colin
Watson on this.

 If so, why are these modifications not included upstream?

Because I never submitted them.

 I cannot find anything in the Debian archive the even build depends on
 imake. Maybe we should prune some of the unused macros.

If you need imake, you B-D on the package that contains it.

$ dpkg -S bin/imake
xutils: /usr/X11R6/bin/imake

$ % grep-dctrl -F Build-Depends,Build-Depends-Indep -s Package xutils 
/var/lib/apt/lists/http.us.debian.org_debian_dists_unstable_main_source_Sources 
|wc -l
271

Perhaps not all of those build-depend on imake (there are other things
in xutils), but I'll bet you most of them do.

I disagree with your premise and your conclusion.

-- 
G. Branden Robinson| When I die I want to go peacefully
Debian GNU/Linux   | in my sleep like my ol' Grand
[EMAIL PROTECTED] | Dad...not screaming in terror like
http://people.debian.org/~branden/ | his passengers.


signature.asc
Description: Digital signature


Re: patch 004 is overkill

2004-01-14 Thread Warren Turkal
Branden Robinson wrote:

 That too.  :)  I also wanted to make it possible to reference any
 manual section from within a manual page without hard-coding the section
 numbers.

You wanted the section not to be dependent on the suffix? Is that correct?

 Because I never submitted them.

May I submit them. I doubt DD will accept them, but I would like to try.

 If you need imake, you B-D on the package that contains it.
 
 $ dpkg -S bin/imake
 xutils: /usr/X11R6/bin/imake

I figured that out after the message. Oops :-)

 $ % grep-dctrl -F Build-Depends,Build-Depends-Indep -s Package xutils
 /var/lib/apt/lists/http.us.debian.org_debian_dists_unstable_main_source_Sources
 |wc -l 271

 Perhaps not all of those build-depend on imake (there are other things
 in xutils), but I'll bet you most of them do.

Maybe imake should be split into its own package so that this can be more
easily tracked?

 I disagree with your premise and your conclusion.

That is probably more sane than me :-). I was trying to make patches smaller
for the 4.4 cycle. Thanks for discussing this with me.

wt
-- 
Warren Turkal
President, GOLUM, Inc.
http://www.golum.org



Re: patch 004 is overkill

2004-01-13 Thread Branden Robinson
On Sun, Jan 11, 2004 at 05:56:14PM -0600, Warren Turkal wrote:
 Short Description:
 Okay, if you used the patch I supplied, you will get the manpages in the
 same places with the same names as we use in Debian. This all uses the
 internal support in the XF86 build system.

[snip]

You appear to be overlooking some of the purpose of my patch.  Consider
the phenomenon of a game with a manpage, which uses imake as its build
system.

-- 
G. Branden Robinson|   The software said it required
Debian GNU/Linux   |   Windows 3.1 or better, so I
[EMAIL PROTECTED] |   installed Linux.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature


Re: patch 004 is overkill

2004-01-11 Thread Branden Robinson
On Thu, Jan 08, 2004 at 06:54:49AM -0600, Warren Turkal wrote:
 Patch 004 is overkill for making the manpages appears with the right names
 in the right places.

I need you to spend more time justifying this statement, please.

-- 
G. Branden Robinson|
Debian GNU/Linux   | Cogitationis poenam nemo meretur.
[EMAIL PROTECTED] |
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature


Re: patch 004 is overkill

2004-01-11 Thread Warren Turkal
Branden Robinson wrote:

 On Thu, Jan 08, 2004 at 06:54:49AM -0600, Warren Turkal wrote:
 Patch 004 is overkill for making the manpages appears with the right
 names in the right places.
 
 I need you to spend more time justifying this statement, please.

Short Description:
Okay, if you used the patch I supplied, you will get the manpages in the
same places with the same names as we use in Debian. This all uses the
internal support in the XF86 build system.

Longer Description:
The 004 patch that I am referring to is
004_imake_manpage_handling_overhaul.diff. In this patch, there appears to
be an effort to break the tie between the name and the location of a
manpage.

I hold that this is not neccessary in XF86 4.3.0. By default, manpages are
installed in the $(MANSOURCEPATH)$(manpagesection)/$(manpagename)
$(mansuffix).

In XF86, $(MANSOURCEPATH) is /usr/X11R6/man/man. The manpage section depends
on various imake configuration settings. The manpage name is defined by the
file that generates the manpage. The manpage suffix also depends on various
imake configuration settings.

The XF86 build system has 5 different kinds of manpages.

1) Regular manpages
2) Library API manpages
3) File format manpages
4) Driver manpages
5) Misc manpages (the info about X.org is here)

Each of these types of manpages has two attributes: (1) ManDir and (2)
ManSuffix.

I will take ManSuffix first. With respect to the types of manpages listed
above, the following are the man suffix configuration options.

1) ManSuffix
2) LibManSuffix
3) FileManSuffix
4) DriverManSuffix
5) MiscManSuffix

By default, linux.cf makes the following definitions for the suffixes.
#ifndef ManSuffix
# define ManSuffix  1x
#endif
#ifndef LibManSuffix
# define LibManSuffix   3x
#endif
#ifndef FileManSuffix
# define FileManSuffix  5x
#endif

My preliminary patch adds the following defines within the LinuxDistribution
== LinuxDebian section.

# define DriverManSuffix   4x
# define MiscManSuffix 7x

Now the man sections must be modified appropriately. Again with repect to
the types of manpages, these are the man dir configuration settings.

1) ManDir
2) LibmanDir (yes, it is a small m on the man part)
3) FileManDir
4) DriverManDir
5) MiscManDir

By default, the man section is the same as the ManSuffix for each section.
Further, linux.cf provides to following definitions.

#ifndef ManDir
# define ManDir $(MANSOURCEPATH)1
#endif
#ifndef LibmanDir
# define LibmanDir  $(MANSOURCEPATH)3
#endif
#ifndef FileManDir
# define FileManDir $(MANSOURCEPATH)5
#endif

My preliminary patch adds the following defines within the LinuxDistribution
== LinuxDebian section.

# define DriverManDir  $(MANSOURCEPATH)4
# define MiscManDir$(MANSOURCEPATH)7

This takes care of Debian Linux. My patch did not modify the other
architectures.

That said, I believe that my patches definitions would be better grouped
with the other definitions that are already in linux.cf as my additions
bring it in compliance with Filesystem Hierarchy Standard. The gnu.cf has a
similar section. I guess that bsd needs to same somehow. I don't know what
file to edit for bsd.

Essentially, the following should be in each file for architectures that we
support.

#ifndef ManSuffix
# define ManSuffix  1x
#endif
#ifndef ManDir
# define ManDir $(MANSOURCEPATH)1
#endif
#ifndef LibManSuffix
# define LibManSuffix   3x
#endif
#ifndef LibmanDir
# define LibmanDir  $(MANSOURCEPATH)3
#endif
#ifndef DriverSuffix
# define DriverManSuffix 4x
#endif
#ifndef DriverManDir
# define DriverManDir   $(MANSOURCEPATH)4
#endif
#ifndef FileManSuffix
# define FileManSuffix  5x
#endif
#ifndef FileManDir
# define FileManDir $(MANSOURCEPATH)5
#endif
#ifndef MiscManSuffix
# define MiscManSuffix  7x
#endif
#ifndef MiscManDir
# define MiscManDir $(MANSOURCEPATH)7
#endif

wt
-- 
Warren Turkal
President, GOLUM, Inc.
http://www.golum.org