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() orADD_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:

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.

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.

Provide longer support.

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.

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.

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.