[gentoo-dev] Last rites: Rails 5.0
# Hans de Graaff (1 Dec 2018) # Old Rails 5.0 version. This version is no longer maintained # upstream. Please update to Rails 5.1 or newer. # Masked for removal in 30 days. dev-ruby/rails:5.0 dev-ruby/railties:5.0 dev-ruby/activerecord:5.0 dev-ruby/actionmailer:5.0 dev-ruby/actionpack:5.0 dev-ruby/actionview:5.0 dev-ruby/activejob:5.0 dev-ruby/actioncable:5.0 dev-ruby/activemodel:5.0 dev-ruby/activesupport:5.0 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [pre-GLEP r3] Gentoo binary package container format
On 2018.11.30 17:06, Michał Górny wrote: > On Mon, 2018-11-26 at 21:43 +, Roy Bamford wrote: > > On 2018.11.26 18:58, Michał Górny wrote: > > > Here's the newest version. > > > > > > Changes: > > > > > > - added explicit notion of parent directory (missing in previous > GLEP > > > but present in implementation), > > > > > > - explicitly named GNU tar format with list of permitted > extensions, > > > > > > - changed volume label to 'gpkg-1.txt' file to improve > portability; > > > made > > > it explicit version identifier as well, > > > > > > - added info on other package formats to rationale. > > > > > > > [snip] > > > > The image archive stores all the files to be installed by the binary > > package. It should be included as the last of the files in the > binary > > package container. > > > > [snip] > > > > > > -- > > > Best regards, > > > Michał Górny > > > > > > > Its a nit today but that says that any future extensions, none > > yet planned, should be placed before the image archive. > > Yes. > > > The specification needs to avoid the use of relative references. > > > > I don't understand. Could you be more specific what you expect > instead? > > -- > Best regards, > Michał Górny > Michał, Enumerate the elements, in the preferred order, which you have already done. The is no need, in a specification that is intended to be easily extensible to specify that any element should be last. That constrains extensions. To build on an example extension given earlier. Suppose an extension came along to add the ebuild, required eclasses and sources. The present wording says that they should be included before image archive. Implementations may be capable of working with partial downloads, why force the download of elements that may not be required to get the payload. The overhead of the presently define elements is small compared to the image and its useful to be able check the metadata to determine if the image is really what is required. image 'last' works with the presently defined elements but may not be so good in the years to come. Its a subtle difference between 'last', which means always at the end, no mater what, and 'fifth' which is last today but might not be in the future. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgp_Ox59p3DZ7.pgp Description: PGP signature
Re: [gentoo-dev] [pre-GLEP r4] Gentoo binary package container format
Hi, Here's hopefully the last update for some time (that is, before I get to working on implementation). There are two small changes: - clarified the text on top archive directory: mentioned it shouldn't have an explicit member in the archive and that the implementations should be ready to handle mismatched directory name (i.e. when archive ends up being renamed), - removed .txt suffix from 'gpkg-1' package identifier file. --- GLEP: Title: Gentoo binary package container format Author: Michał Górny Type: Standards Track Status: Draft Version: 1 Created: 2018-11-15 Last-Modified: 2018-11-30 Post-History: 2018-11-17 Content-Type: text/x-rst --- Abstract This GLEP proposes a new binary package container format for Gentoo. The current tbz2/XPAK format is shortly described, and its deficiences are explained. Accordingly, the requirements for a new format are set and a gpkg format satisfying them is proposed. The rationale for the design decisions is provided. Motivation == The current Portage binary package format - The historical ``.tbz2`` binary package format used by Portage is a concatenation of two distinct formats: header-oriented compressed .tar format (used to hold package files) and trailer-oriented custom XPAK format (used to hold metadata) [#MAN-XPAK]_. The format has already been extended incompatibly twice. The first time, support for storing multiple successive builds of binary package for a single ebuild version has been added. This feature relies on appending additional hyphen, followed by an integer to the package filename. It is disabled by default (preserving backwards compatibility) and controlled by ``binpkg-multi-instance`` feature. The second time, support for additional compression formats has been added. When format other than bzip2 is used, the ``.tbz2`` suffix is replaced by ``.xpak`` and Portage relies on magic bytes to detect compression used. For backwards compatibility, Portage still defaults to using bzip2; compression program can be switched using ``BINPKG_COMPRESS`` configuration variable. Additionally, there have been minor changes to the stored metadata and file storage policies. In particular, behavior regarding ``INSTALL_MASK``, controllable file compression and stripping has changed over time. The advantages of tbz2/XPAK format -- The tbz2/XPAK format used by Portage has three interesting features: 1. **Each binary package is fully contained within a single file.** While this might seem unnecessary, it makes it easier for the user to transfer binary packages without having to be concerned about finding all the necessary files to transfer. 2. **The binary packages are compatible with regular compressed tarballs, most of the time.** With notable exceptions of historical versions of pbzip2 and the recent zstd compressor, tbz2/XPAK packages can be extracted using regular tar utility with a compressor implementation that discards trailing garbage. 3. **The metadata is uncompressed, and can be efficiently accessed without decompressing package contents.** This includes the possibility of rewriting it (e.g. as a result of package moves) without the necessity of repacking the files. Transparency problem with the current binary package format --- Notwithstanding its advantages, the tbz2/XPAK format has a significant design fault that consists of two issues: 1. **The XPAK format is a custom binary format with explicit use of binary-encoded file offsets and field lengths.** As such, it is non-trivial to read or edit without specialized tools. Such tools are currently implemented separately from the package manager, as part of the portage-utils toolkit, written in C [#PORTAGE-UTILS]_. 2. **The tarball compatibility feature relies on obscure feature of ignoring trailing garbage in compressed files**. While this is implemented consistently in most of the compressors, this feature is not really a part of specification but rather traditional behavior. Given that the original reasons for this no longer apply, new compressor implementations are likely to miss support for this. Both of the issues make the format hard to use without dedicated tools, or when the tools misbehave. This impacts the following scenarios: A. **Using binary packages for system recovery.** In case of serious breakage, it is really preferable that the format depends on as few tools a possible, and especially not on Gentoo-specific tools. B. **Inspecting binary packages in detail exceeding standard package manager facilities.** C. **Modifying binary packages in ways not predicted by the package manager authors.** A real-life example of this is working around broken ``pkg_*`` phases which prevent the package from being installed. OpenPGP
Re: [gentoo-dev] [pre-GLEP r3] Gentoo binary package container format
On Mon, 2018-11-26 at 21:43 +, Roy Bamford wrote: > On 2018.11.26 18:58, Michał Górny wrote: > > Here's the newest version. > > > > Changes: > > > > - added explicit notion of parent directory (missing in previous GLEP > > but present in implementation), > > > > - explicitly named GNU tar format with list of permitted extensions, > > > > - changed volume label to 'gpkg-1.txt' file to improve portability; > > made > > it explicit version identifier as well, > > > > - added info on other package formats to rationale. > > > > [snip] > > The image archive stores all the files to be installed by the binary > package. It should be included as the last of the files in the binary > package container. > > [snip] > > > > -- > > Best regards, > > Michał Górny > > > > Its a nit today but that says that any future extensions, none > yet planned, should be placed before the image archive. Yes. > The specification needs to avoid the use of relative references. > I don't understand. Could you be more specific what you expect instead? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs: dev-python/{cliapp,CoverageTestRunner,larch,tracing,ttystatus} dev-util/cmdtest
Hello, The following packages are up for grabs. Since obnam has gone I have no use for them anymore: Package # open bugs needs bump? dev-python/CoverageTestRunner 1* yes dev-python/cliapp 3* no dev-python/larch1no dev-python/tracing 0no dev-python/ttystatus2* yes dev-util/cmdtest1* yes [*] There is one open keywording request for multiple packages: https://bugs.gentoo.org/530672 -Marc -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5
