IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Recent changes left downgradeLzmaLevel dysfunctional (because it does
not recognize 'T'). In my view, the only advantage of XZ over LZMA is
that XZ can can split input into blocks and compress them in parallel
(resulting in a speed-up). Other advantages, such as a checksum, are
immaterial for our purpose (because the package manager must verify the
integrity of a package beforehand). Therefore, downgradeLzmaLevel will
also downgrade XZ->LZMA automatically, for payloads smaller than
5*dictSize (the default blockSize being 3*dictSize, so that there are
at least two blocks, the second block not too small).
When hasher generates an src.rpm from pkg.tar, it sets $SOURCE_DATE_EPOCH
according to pkg.tar's specfile modification time which in turn is set to
the corresponding commit time.
When hasher builds from an src.rpm, it sets $SOURCE_DATE_EPOCH according
to the src.rpm's RPMTAG_BUILDTIME.
This changes helps to connect these two stages, setting the
RPMTAG_BUILDTIME of the generated src.rpm to $SOURCE_DATE_EPOCH.
Co-Authored-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
These are the cases where even the release was not needed (so, the
disttag is not needed, too), or one case where the filename is
contructed (and it doesn't include the disttag).
Now grep -Ee 'headerNVR[^D]' will show the remaining non-trivial
cases, where adapting to disttags may be needed.
- Implemented limited support for large files: a 2GB+ file can now be packaged,
but the total size of uncompressed cpio payload is capped at 4 GB.
- Automatically downgrade LZMA compression levels 7-9 -> 6 on small payloads.
The nearest goal is to be able to package files up to 4G, on both 32-bit
64-bit architectures, provided that cpio payload size also does not
exceed 4G. More specifically, the limit is 2^32-2, while 2^32-1 remains
special (this is not my own invention, I adopt it from rpm.org).
If the limit is exceeded, rpmbuild should fail gracefully instead of
writing malformed packages with truncated integer tags.
(Supporting 4G+ files is a distant goal - neither rpm-4.0 nor apt-rpm
can handle them yet. Besides, it's not clear if producing such big
packages is even a good idea, unless one wishes to package p0rn.)
Some code (e.g. apt/genpkglist) explicitly relies on the fact that
header file list is represented with baseNames+dirNames+dirIndexes
arrays. Thus, generating legacy headers might have issues, and should
be disabled.
