Package Details: unicode 3.2-1

Git Clone URL: https://aur.archlinux.org/unicode.git (read-only, click to copy)
Package Base: unicode
Description: Display unicode character properties on the command line
Upstream URL: https://github.com/garabik/unicode
Licenses: GPL-3.0-only
Submitter: taimon
Maintainer: Rhinoceros
Last Packager: Rhinoceros
Votes: 15
Popularity: 0.000000
First Submitted: 2009-03-11 08:44 (UTC)
Last Updated: 2025-09-10 00:55 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

Rhinoceros commented on 2016-07-12 01:30 (UTC)

> Your happiness is irrelevant. @felix.s That's rather aggressive response, for a mere misunderstanding about your terse phrasing. In any case, I'll monitor the bug report before I resolve anything here. @kseistrup That's possible, but I'm not sure how to do that cleanly with the PKGBUILD. AFAIK the only way would be to have both the minimal package and the full UCD as optdepends, meaning that users could easily miss the info, and not have the correct dependencies installed.

kseistrup commented on 2016-07-05 08:43 (UTC)

Could another solution be to package the UNIDATA needed for unicode separately and then let unicode depend on either that separate package or the UCD package. Explain to the user that uncode can use the UCD package but that it takes up 73 MB, or that it can use the smaller UNIDATA package, then ask the user if they want (1) or (2).

felix.s commented on 2016-07-05 07:58 (UTC)

Your happiness is irrelevant. Separation of concerns is about preventing file conflicts: what happens when you want to install two packages each containing a file named /usr/share/unicode/UnicodeData.txt? (For extra perversion, each a different version.) I already filed a bug report in which I suggested reducing the size and/or splitting the UCD package: <https://bugs.archlinux.org/task/49938>. The largest part of the UCD is the Unihan database (33M), and it turns out this very tool you're packaging here can in fact use it. So it isn't all cruft as you imply.

Rhinoceros commented on 2016-07-05 05:33 (UTC)

For your first two points, I'm happy enough to package, and relatively unconcerned. :) I agree that there is some redundancy the way it is, but 97.5% of the UCD is unnecessary for this package. It just seems like overkill to me. Also, TBH I'm also reticent because I personally don't have the UCD installed. I might be convinced if I'd could be shown that the UCD is a very popular package, but AFAIK it's not possible to show that data. I have to assume that for many users it would mean installing an additional package for no reason. The alternative is to leave it as it is, and have this redundancy of 1.7M (instead of installing an additional 71M).

felix.s commented on 2016-07-04 11:11 (UTC)

Ease of packaging, separation of concerns and reducing redundancy. There are other software that need to have the UCD installed somewhere; and both depending on this utility and packaging it on their own is suboptimal. It easily follows the UCD should be kept in a dedicated package. Luckily enough, there's already one in [extra].

Rhinoceros commented on 2016-07-04 10:20 (UTC)

@felix.s I was not aware of that package… it sounds reasonable. However, I'm leaning towards not doing that, just because it's a 73M package compared to this one which is 1.8M. Was your suggestion mainly based on ease of packaging? If so, then I'm happy enough to just monitor the files for the sake of minimising space/downloads, unless there's a compelling reason not to? Thanks for the hint, though.

felix.s commented on 2016-07-04 09:41 (UTC)

Maybe you should depend on unicode-character-database from [extra] instead of embedding the UCD in this package.

Rhinoceros commented on 2016-06-24 10:04 (UTC)

@kseistrup Fixed. They must have pushed a new version; I'll monitor the links from now on. Thanks for the comment.

kseistrup commented on 2016-06-24 09:19 (UTC)

{Blocks,UnicodeData}.txt currently both fail the SHA256 check.

« First ‹ Previous 1 2 3 4 Next › Last »