On Tue, 31 Dec 2019 10:32:31 +0100
Slávek Banko <slavek.banko(a)axis.cz> wrote:
On Monday 30 of December 2019 22:43:06 E. Liddell
wrote:
> On Mon, 30 Dec 2019 10:02:24 +0100
>
> Slávek Banko <slavek.banko(a)axis.cz> wrote:
> > On Friday 27 of December 2019 14:39:02 E. Liddell wrote:
[snip
discussion of How Ebuilds Work]
Thank you, now I understand better. This means there is no need to create a
branch. It also means that tde-packaging-gentoo will not be part of
the 'tde' tree on r14.0.x branch.
Is there also a convention for preliminary packages? For example, as on
Debian "~preXX", or on FreeBSD "+pXX"?
You would add "_preXX" to the version number. "XX" can either be a
simple number or a compressed date (for instance,
tdelibs-14.1.0_pre20201031.ebuild, for something that captures the state
of the source as of next Halloween). Corresponding source tarballs would
need to be available, though.
Ugh.
That's messy. Especially since the source releases only place
the 14.x.y package version in the filename, which means that the
ebuild needs to know that number *anyway*, even though it's
technically irrelevant.
I think I'm going to leave it as-is, with directory=tqt3, SLOT=3
(SLOT=3.5.0? I'll have to see if that's allowed), but ebuild version
14.x.y. It may lead to some people updating that package
unnecessarily, but it won't actually break anything.
It's not as crazy as it may seem. TQt simply has a version that
complies with the TDE itself. So in stable branch it is now 14.0.7.
That's why the package version is 14.0.7 - I suppose you can use it
for Gentoo anyway.
Libraries themselves have an internal version number determined by API
/ ABI changes and backward compatibility. Therefore, it is not unusual
for individual libraries to have internal version numbers different
from the package version itself. For example, you can see
libtqt-mt.so.3.5.0 and libtqui.so.1.0.0 side by side in the same
package. Regardless of the fact that the version number of the package
as a whole is 14.0.7.
The idea here is to keep people from having to download and compile
tqt3-trinity-14.0.8.tar.xz if tqt3-trinity-14.0.7.tar.xz is already
installed and provides the same code. Depending on the SLOT rather than
the package version should work for this, but I have to make sure I know
when to change the SLOT (it has to reflect API and ABI).
I'm afraid we're not careful here. For example, in the master branch, the
TQt1 and TQt2 compatibility functions (which never existed as TQt) have
been removed, but we still did not change the internal version number.
Portions of the API that aren't called by any current consumer of the package
are of concern only in a perfect-world, abstract way, if you understand what
I mean. Is it reasonable to expect a bump of the internal version if portions of
the API in active use change?
E. Liddell