30 Dec
2019
30 Dec
'19
9:43 p.m.
On Mon, 30 Dec 2019 10:02:24 +0100
Slávek Banko <slavek.banko(a)axis.cz> 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
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'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.
In that case, I'll do an about-face and wait and see if anything blows up.
I can only see one relevant commit, back in 2011:
https://mirror.git.trinitydesktop.org/gitea/TDE/libart-lgpl/commit/150562b8…
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.
E. Liddell
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.
(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.)
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. 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 :) What is the
actual version number of tqt? Of tqtinterface?
Historically, these followed a different version scheme from the
main desktop, but that seems to have changed. Currently, I'm dealing
with the version numbers, certain directory and file names, and a
Gentoo SLOT (mechanism for tracking multiple versions of the same
package installed in parallel) inconsistently, and I would like to
clean things up.
Here are two numbers - the git repository versions and packages follow
the TDE version numbering as a whole. However, the internal version
number of the library is now 3.5.0. For deb packages, the package
version is now 14.0.7, where the so library version inside the package
is 3.5.0. What, exactly,
are msg2qm and qembed? The ebuild I inherited for
tqt builds them separately, with comments reading "# Make the
msg2qm[/qembed] utility (not made by default)", and furthermore the
build mechanism is currently broken. I need to know whether or not
fixing it is worth the effort. Are these utilities used for
building and/or running anything?
msg2tqm (tqembed) is a tool for converting data, such as images, into
C++ code that can be embedded as part of a binary. Unfortunately, I do
not remember whether / where this tool is actually used. However, for
deb packages it is also built as part of TQt. 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.