[CMake] [CPack] Preprocess or postprocess for make package* targets

CPack can pack source and binary accourding to
CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR, CPACK_PACKAGE_VERSION_PATCH
and CPACK_SOURCE_IGNORE_FILES, CPACK_PACKAGE_IGNORE_FILES in CMakeLists.txt.

CMake then produce targets like package, package_source, however,
CMake itself does not recognize the these targets. So we cannot associate and
depend any targets by either ADD_CUSTOM_COMMAND() or
ADD_DEPENDENCIES()

, in other words, CMake does not recognize package, package_source itself.

But what if you do want to associate some commands and targets before or after the package is built?
Here is some quick hack: Use a target: pack_src for package_source,
just like:

ADD_CUSTOM_TARGET(pack_src COMMAND make package_source COMMENT "Packaging Source files" DEPENDS other_dependency VERBATIM )

Note that I have to add package_source, as CMake does not recognize package_source, and I need to call it explicitly.

About the Fedora LTS support (2)

After I posted my thought about the Fedora LTS, I got many valuable replies. Especially on security updates, binary compatibility, and the over-complexity of my proposal. I talked with guys around me, they also showed the similar concert, may be more like Jesse Keating’s.

After hearing these valid concerns, I think the current Fedora version scheme need not be change at the present, as it is a big attraction for technology-chaser.

Then how to support the old release, while make the minimal impact to the main stream users and developers? I am thinking a package compatibility database, in following format:

Package	Operator	Version	Release	Compatibility Type
PkgA	<	1.0-1	F8	binary
PkgA	>=	1.0-1	F9	binary
PkgA	>=	1.0-1	F10	binary
PkgB	>	2.0-0	F8	source

Binary compatibility means you can directly install from it, while source compatibility means you have to rebuild it for the target release. Not in the list means no support.

For package maintainers, they can choose what releases do they want to support; and users know what package update are current support in their system.

About Fedora LTS support.

You maybe aware that the recent discussion about how to tackle the Ubuntu after they “take over” the Wikipedia in fedora-devel mail. Simply put, there are two kinds of opinions.

1. Provide longer support.
2. Keep Fedora as it is – innovative, fast paces, need not care too much about the outdated version.

IMHO, why mutually exclude each other, why can’t we have them both?
Is there a way to have shiny new stuff in our show cases, while still embracing our existing users for longer period? The scheme I have in mind is:

Major version and “plus” version

The release of major version is lengthen to one year, while we have ‘plus’ version between major version.
For example, major version as 11, and plus version as 11+.

Basically, plus version is just like major version, all the shiny new features, major libraries,
even fundamental gcc or python major version change can go in to the plus. In other word, version 11+ does not necessary 100% compatible with version 11.

However, there are two repositories for “plus”: “COMPATIBLE” which stores the packages which are known to be buildable and runnable in the major release; and “EXCLUSIVE” which stores the packages which are known incompatible with the (i.e. the major release), as well as rest of the packages whose behavior is uncertain with prior release.

Major releases also have “COMPATIBLE” and “EXCLUSIVE”.
In major release, “COMPATIBLE” means it supports the prior major release (but not necessary the Plus); while “EXCLUSIVE” stores the the packages that does not guarantee that they can work in prior major release.

Benefits of this approach

The beauty of this scheme is it fits both need from technology chasers and conservative users.
For technology chasers, they can follow 11, 11+, 12, 12+ and so on; while for conservative users,
they can stay with 11 for 1.5 years, as they can receive updates from COMPATIBLE repositories of 11+ and 12.

The “COMPATIBLE” and “EXCLUSIVE” looks like of a bit complex, but it is not.
By default, the new packages will go to EXCLUSIVE.
If package maintainers clearly know their packages, or there are great demands from community,
the packages can moved to COMPATIBLE after testing.
Unchanged packages from prior release can go to COMPATIBLE, as they are already used in prior release.

It also handle the major changes in fundamental packages such as gcc, Python, and glib.
For example, Python 2.6 is released, so the Python 2.5 related packages can go to COMPATIBLE, while 2.6 can go to EXCLUSIVE.

Any concerns about it?

Are Pinyin and Zhuyin functional dependent on each other? Not really.

Many people think that Hanyu pinyin and Zhuyin are functional dependent on each other, that is, Hanyu pinyin can be converted to Zhuyin without losses, and vice versa.[1] I used to hold this belief, until I start developing libUnihan 0.5.

Originally, Hanyu pinyin design does have two-way functional dependency with Zhuyin.
however, practically Hanyu pinyin only cover 414/416 ~ 99.519% of Zhuyin (without tonemark).
The two exceptions are:

Zhuyin symbols and their pinyin equivalents	Usually map to	Example
ㄝ(ê), ㄜ(e)	e	誒 (ㄝˋ) 惡 (ㄜˋ） are all map to è
ㄌㄩㄢ(lüan),ㄌㄨㄢ(luan)	luan	攣(ㄌㄩㄢˊ)鸞(ㄌㄨㄢˊ) are all map to luán

Nevertheless, since some lüán do have luán as alternative pronunciation (such as 孿); and 誒 is sometimes interchangeable with 欸 (èi), which also sounds similar, no wonder almost none spot the difference.

BTW, there are couples of errors in [1]:

1. Distinctive syllables should be 416, not 417, as no one actually pronounces 淋 as ㄌㄩㄣˊ (lǘn).
2. 佛, 否, … etc. does have Zhuyin equivalent in pinyin.
3. ㄜ, ㄝ cannot be distinguished by the rule he suggests. As explained earlier, ㄝ seems to be eaten alive if no medials (ㄧ,ㄩ) protect it.

The author also wondering whether Pinyin to Zhuyin conversion is workable. I can tell him now that his program works 99.519% of times if he were putting some effort on it. 🙂

Reference:

1. 1. 注音符號轉漢語拼音、兩個多年前的心願