Debarshi Ray wrote:
Going through the entire debate, here is what I think would be the
best thing to do. This is infact quite similar to Otavio

Have the configure script find out whether po4a is present or not. If
it is absent then say so and only build the canonical English version
of the documentation. Now in case it is present then we can have two
scenarios. Either we build all the available languages, or we only
build a particular language specified by the user as a parameter to
the configure script. The default behavior could be to make all
languages if po4a is there, and only stick to a particular language
(even English) if one is specified to the configure script. Hopefully
this will not frustrate the distributors, since they can easily
restrict the documentation to a particular language (even English) or
let all available languages be present.

I don't like this approach because the way all languages are built becomes a side effect of the configure process. Under this method, it's not clear to the person installing how to get ALL languages built.

What I would like is English always since we really only need iconv to build those and a configure switch to enable the other languages that require po4a. The configure switch should cause a test for po4a to run and if it fails, the configure script should FAIL completely. This makes it perfectly clear to the person installing what is required to get all languages to build. I don't want the test to fall back on English only if po4a is not found. If the user wants to install without po4a, they can remove the configure switch enabling the po4a languages.

Now what happens when a user had asked for a specific language and the
system does not have po4a to make the translations? The configure
script can output a message and either stop there, or continue to
build the English version which does not need po4a.

Output a message and stop there.

To top it all, we can also provide an option to completely avoid
installation of any documentation. This must not be a default
behaviour, since it only makes sense in the case of LiveCDs and
installers where storage space is a scarcity.

I don't think this matters at all. Our make install target doesn't need to cater to each use case for parted. People producing LiveCDs can pick and choose things from the parted source directory after building.

--
David Cantrell
Red Hat / Westford, MA

_______________________________________________
parted-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/parted-devel

Reply via email to