On Tue, 31 Dec 2019 10:32:31 +0100 Slávek Banko <slavek.banko@xxxxxxx> 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@xxxxxxx> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@xxxxxxxxxxxxxxxxxxxxxxxxxx For additional commands, e-mail: trinity-devel-help@xxxxxxxxxxxxxxxxxxxxxxxxxx Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
