Re: [Quilt-dev] distributing the files (was: [Quilt-cvs] quilt configure.ac quilt.changes)

[Martin Quinson]

On Thu, Nov 20, 2003 at 01:38:03PM +0100, Andreas Gruenbacher wrote:
> On Thu, 2003-11-20 at 14:09, Martin Quinson wrote:
> > Hello,
> > 
> > On Thu, Nov 20, 2003 at 12:10:13PM +0100, Andreas Gruenbacher wrote:
> > > Hi Martin,
> > > 
> > > On Thu, 2003-11-20 at 12:11, Martin Quinson wrote:
> > > > In the same time, I'll update the list of scripts in po/Makefile and
> > > > translate the missing strings to french. The best would be to use the 
> > > > same
> > > > list for both ./Makefile and po/Makefile, but it would need to split the
> > > > variable definition out of the ./Makefile to include those definitions 
> > > > in
> > > > po/Makefile. That's a bigger change I do not trust myself to do since 
> > > > I'm
> > > > not very familiar with your makefile...
> > > 
> > > Is there a problem with using the full list of commands and scripts?
> > > `bash --dump-po-strings' seems to do the right thing ...
> > 
> > Yes, but you have to list the scripts in the QUILT_IN variable, which is
> > also defined in root Makefile, thus my idea of the creation of a Makevars,
> > and its inclusion in both the root Makefile and the po/Makefile. That ways,
> > the po files will never lag behind in case of inclusion of new commands 
> > again.
> 
> It should also be possible to pass a variable to a sub-make with
> something like:
> 
> BLUBB := hello
> export BLUBB
> 
> all:
>       $(MAKE) -f sub/Makefile all

Wont work if I call the po file from inside the directory. And I have to do
so to update the quilt.pot and fr.po files before beginning translating.

> > IIRC, compiled stuff goes to lib, but having hardcoded paths is not a
> > sufficient reason to go there (in the spirit of the FHS). I'll try to check
> > this again...
> 
> The idea of /usr/share is that it can be shared among multiple systems
> which may differ in other respects (architecture, configuration, etc.).

>>>>>>>>>>>>>>>>>>
FHS 2.2, section 4.7 (/usr/lib)

Applications may use a single subdirectory under /usr/lib. If an application
uses a subdirectory, all architecture-dependent data exclusively used by the
application must be placed within that subdirectory.

Section 4.11 (/usr/share)

The /usr/share hierarchy is for all read-only architecture independent data
files.

This hierarchy is intended to be shareable among all architecture platforms
of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms
might maintain a single /usr/share directory that is centrally-mounted.
Note, however, that /usr/share is generally not intended to be shared by
different OSes or by different releases of the same OS.

Any program or package which contains or requires data that doesn't need to
be modified should store that data in /usr/share (or /usr/local/share, if
installed locally). It is recommended that a subdirectory be used in
/usr/share for this purpose.
<<<<<<<<<<<<<<<<<
http://www.pathname.com/fhs/2.2/


So, nope, we don't have to make sure that /usr/share will be system
independent since the content of this dir is to be shared between several
architectures of the same system. And it would be 'forbiden' to move them to
/usr/lib since they are not arch-dependent...


Thanks for your time, Mt.

signature.asc
Description: Digital signature