31 Dec
2019
31 Dec
'19
9:32 a.m.
On Monday 30 of December 2019 22:43:06 E. Liddell wrote:
Normally, Gentoo uses one ebuild file per package version, and they're
all held in one directory together. For instance, if we had a working
overlay at this time, the directory for tdelibs would contain
tdelibs-14.0.6.ebuild, tdelibs-14.0.7.ebuild, and tdelibs-9999.ebuild
(by Gentoo convention, a "live" ebuild that pulls from source control
rather than a prepackaged release is always version 9999). That's the
direction I'm trying to head in.
If version 14.0.8 came out, I'd then copy tdelibs-14.0.7.ebuild to
tdelibs-14.0.8.ebuild, then build and test the package to make certain
that the ebuild didn't need to be modified.
If version 14.1.0 came out, I'd copy tdelibs-9999.ebuild to
tdelibs-14.1.0.ebuild, fix the KEYWORDS variable, and build, test, etc.
How does the package manager know whether or not to install tdelibs-9999
if I ask for an update? That's what KEYWORDS is for. Release versions
would be keyworded ~amd64 (non-stable keyword for x86_64 systems) and
possibly ~arm (non-stable 32-bit ARM, like the Raspberry Pi) and/or ~x86
(non-stable 32-bit Intel x86) depending on how much testing I have the
energy for. (As for stable keywords, they're not supposed to be issued
by anyone other than official Gentoo devs or QA.)
9999 versions carry no keywords at all (again, this is Gentoo
convention) and have to be unmasked specifically. It's generally
understood that software with no keywords may fail to build, exhibit
random runtime failures, turn your cat into a toaster, etc. (Gentoo's
onetime reputation for being bleeding-edge came about for a reason.)
Splitting all of this into "master" and "stable" branches only means
that the people pulling the "stable" branch might get stale/broken/no
9999 ebuilds. It just isn't supposed to work like that.
If you'd like a sample of how this kind of thing looks in practice,
here's poppler in the official Gentoo ebuild repository, with three
release ebuilds and one live ebuild:
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/poppler
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"?
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.
In that case, I'll do an about-face and wait and see if anything blows
up.
Yes, it probably can be left for later.
We'll see if Chris devoted himself to it :)
I can only see one relevant commit, back in 2011:
https://mirror.git.trinitydesktop.org/gitea/TDE/libart-lgpl/commit/15056
2b89b645c402f1bb837a09f8b84bf6e49ec
The rest seems to be CMake conversion, tweaks to informational files,
and similar. In theory, I could try to submit the patches back to
Gentoo. In practice, I have no idea what they do (what are "a number of
problems"?) or whether they'd break any of the other ten reverse
dependencies of media-libs/libart_lgpl (or whether it matters, given how
old some of them are).
I'm not sure what the best move is here at this point. The
quick-and-messy fix is to provide libart_lgpl-2.3.21-r99.ebuild to
supersede the upstream libart_lgpl-2.3.21-r3.ebuild, but that's an ugly
solution.
For deb packages, we have upgraded the libart-lgpl package version number
to the TDE version number. But it is true that we probably did not
increase the internal version number of the library.
On Mon, 30 Dec 2019 10:02:24 +0100
Slávek Banko <slavek.banko(a)axis.cz> wrote:
You are now a Contributors team member - welcome :)
On Friday 27 of December 2019 14:39:02 E. Liddell
wrote:
Okay, I registered. Account name eliddell, since I can't be bothered to
be creative.
Looks like the copy is all that's there right
now. I'll have to
reread some documentation, since I mostly use mercurial rather than
git, and register myself with the current system.
Michele has already sent a link to the TGW information. Once you have
an account, we will join you in the Contributors team. This will allow
you to create pull-requests. Later we will join you in the Packagers
team. Then you will be able to push the commits directly into the main
branches. (A note: Is there some way to make the registration
page show what the
password complexity requirements are, if you must have them at all?
Counterintuitively, requirements like that actually make passwords
slightly easier to crack when you have a tech-savvy userbase, because
they reduce the number of possible passwords.)
Good question. I don't recall that in Gitea there is any setting for it.
Currently, I have tqt, tqt-interface, and dbus-1-tqt
more-or-less
working. I'll see about getting this into source control once I've
fixed the msg2tqm thing (if I can) and have tdelibs working.
As you can see in tde-packaging for deb packages, it is recommended
that you manage to keep the code consistent between master and r14.0.x
(stable) branch. Usually we use cherry-pick from master branch to
r14.0.x branch.
Therefore, it will be good to align your plans so that the intended
goals work for both branches. It is clear that this will require more
discussion than comments on pull-request :) 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. I'd probably better try to sort it out, then. At
a guess, it's
probably used for some simple icon graphics somewhere.
I found several files in the source code that were generated by
qembed. However, apparently at present there is nothing to use tqembed
during build. libart-lgpl is still in the main Gentoo tree, and TDE
seems to
work fine with that version, so I'm removing it as well.
The version of libart-lgpl in the TDE repository contains bug fixes -
as far as I remember, it was the solution to some crashes. E. Liddell
Cheers
--
Slávek