New package: dee-1.2.7

[Baysul]

Testing the changes

• I tested the changes in this PR: YES

New package

• This new package conforms to the package requirements: YES

Local build testing

• I built this PR locally for my native architecture, x86_64

[ahesford]

It is hard to justify packaging a project that

• Hasn't tagged a release in more than a decade
• Requires extensive patching to allow it to build with modern tooling
• Is primarily a library and development tools that aren't required by any end-user software in the repository

[Baysul]

It is hard to justify packaging a project that

* Hasn't tagged a release in more than a decade

* Requires extensive patching to allow it to build with modern tooling

* Is primarily a library and development tools that aren't required by any end-user software in the repository

These are all valid points. The main reason for packaging this is because libunity depends on it, which is necessary for certain apps (namely Electron/Chromium-based) to have functioning notification badges on desktops like KDE Plasma.

[ahesford]

We don't package unity or anything that requires it.

[Baysul]

We don't package unity or anything that requires it.

To be clear, I'm not aware of any software that has a hard dependency on libunity, but software like Discord can make use of it for things like notification badges (as I mentioned). I think some other software, such as the element-desktop client can also make use of it, but don't quote me on that.

[ahesford]

Whether or not software can use libunity, we don't provide that package, which means there is no use case for this package.

[Baysul]

Whether or not software can use libunity, we don't provide that package, which means there is no use case for this package.

Right, dee is a hard dependency of libunity, so I'm trying to merge this package into the repository before sending a PR for libunity. Admittedly, there probably isn't any use for dee outside of libunity, but to abide by Void Linux's contribution guidelines, I am separating the two into their own pull requests. I will submit a (still separate) PR for libunity when I get home, if it helps build the case for this package. Sorry for the confusion.

[ahesford]

Packages that depend on each other should not be in separate pull requests. Our CI tests will fail, and it also requires more planning from the maintenance team when pull requests are interdependent. Pull requests should use a single commit per package, but as many packages as necessary to provide a consistent submission.

Regardless, I don't see how libunity provides enough value to overcome the issues with this package, especially given that libunity seems to be a deadend project itself.