Re: [gentoo-dev] About what would be included in EAPI5
On Sun, 2012-06-17 at 13:35 +0200, Peter Stuge wrote: > Hans de Graaff wrote: > > > I think ABI fits well though? The situation is that A DEPENDs on B, > > > and at some point B changes in a way that A must be rebuilt in order > > > to run - right? > > > > At least for dev-ruby/nokogiri this is not the case. It checks the > > version of libxml2 it was built against versus the one it finds at > > runtime and starts to issue warnings if they don't match, but it will > > still run. > > Why does nokogiri issue warnings about something that isn't actually > a problem? I haven't asked upstream, but my guess is that they are trying to be helpful by letting you run against new versions because this usually works out. rmagick is taking the alternative approach. > > dev-ruby/rmagick does something similar for imagemagick but > > actually refuses to run, even if the ABI would stay the same. > > ruby y u so weird? Well, it seems to me that you have to pick one of these two solutions as the sane one, or you must provide lock-step releases that refuse to build against untested new versions, which means locking in your users. Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On Sun, 17 Jun 2012 09:26:55 +0200 Michał Górny wrote: > I'm attaching a reStructuredText version of the spec. You can view it > rendered as a gist[1]. But please keep the replies on the list, rather > than forking the gist. > > [1]:https://gist.github.com/2943774 Updated version. I've introduced dynamic SLOT groups and updated all relevant information. I didn't break DYNAMIC_SLOTS in ebuild to multiple variables yet but it will be easy to change that if necessary. This fixes problem previously described as 9a (dependencies). However, I've added a new issue, 10c which marienz pointed out. -- Best regards, Michał Górny dynamic-slots.txt.rst Description: Binary data signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/06/12 09:37 AM, Pacho Ramos wrote: > El sáb, 16-06-2012 a las 13:43 +0100, Ciaran McCreesh escribió: >> On Sat, 16 Jun 2012 14:26:16 +0200 Pacho Ramos >> wrote: >>> About suggesting new item (like forcing rebuilding of other >>> packages as discussed some days ago and crosscompile support >>> suggested by Tommy today), I guess we need to get them voted by >>> the council? >> >> No. You need to get a draft diff for PMS written, along with an >> implementation in a package mangler of your choice and proof that >> it works in practice. >> > > Umm, this way to work makes any suggestion for future eapis to be > accepted only if they come from people able to prepare that > implementation in the package manager their prefer and, then, be > stalled more and more time :| > This makes sense to me - the original idea can come from anyone, but unless there is support by dev(s) that can maintain the package manager(s) and are willing to implement the proposed change, these ideas won't go anywhere anyways. Council can't make anything be implemented, after all. Also, if there is a working test implementation when the vote happens then it's a fairly quick process to full implementation once the EAPI is approved. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/fM1cACgkQ2ugaI38ACPDJkAD+I1Y/4BSTz8u6QAIepvFj7Pks HoKuSdhyEsZHhD9GGOUA/1qYM8uJ6SZBC3dfJnBQOpXo6ZLz3f7e4lbEIc1BXHbc =td0e -END PGP SIGNATURE-
Re: [gentoo-dev] About what would be included in EAPI5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/06/12 12:18 PM, Ciaran McCreesh wrote: > On Sat, 16 Jun 2012 17:24:22 +0200 Peter Stuge > wrote: >> Ciaran McCreesh wrote: Could it work to make automatic signatures of imported ABI, and simply compare signatures when a provider package is updated? >>> >>> No. >> >> Can you say why? > > There's no way for a program to work out what "the ABI" of > something is (whatever that means), and there's even less of a way > for it to know up-front. > I believe what Peter might've been referring to would be some form of hashing of each and every library that is installed by a package. Just as a basic idea, one could probably (for instance) grab the LTVERSION of a libtool-built library, store that along with the emerge info, and link this same version when consumer ebuilds are built against it; then if the signatures changes the consumer ebuilds that were built against the (now incompatible) old signatures could be triggered for a rebuild. I'm not saying that this is a viable approach, simply describing a theoretical way it could be implemented. One of the "advantages" of going this way, though, is that it would probably be EAPI-independent as everything would be done internally by the PMS. The primary disadvantages I see is that 1-getting "library" signatures would be difficult, 2-many orders of magnitude of additional preprocessing would be necessary to build the deptree, 3-there wouldn't be any viable way for developer-based intervention when necessary. Finally, the above is just an example; I don't want to discuss merits of an approach like this or entertain possible implementations. >>> Also, can we stop using the term "ABI" in reference to this >>> please? It's misleading. Let's call them sub-slots instead. >> >> I think ABI fits well though? The situation is that A DEPENDs on >> B, and at some point B changes in a way that A must be rebuilt in >> order to run - right? >> >> The only reason that A wouldn't run anymore is that B's ABI >> changed? > > ABI has a fairly specific, technical meaning, which can be > misleading in the general case. Is Python bytecode an ABI? > Isn't Python bytecode an ABI, given that it's built or tied to a particular version (major.minor) of python?? (i'm actually asking here, i avoid python so I don't really know if a .pyc from say python-2.5 will just work with python-2.7 or if the original script would need to be recompiled) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/fOPMACgkQ2ugaI38ACPCnpQD9Eu8uT2NABFQpb1ym5GeWUs0L SY+t0wWh6saGXyfVja8BAIYMB0Q21qukus/rH3gDdf98AZYgOiXA20tg+dQyHZ26 =grcA -END PGP SIGNATURE-
Re: [gentoo-dev] About what would be included in EAPI5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/06/12 12:24 PM, Ciaran McCreesh wrote: > On Sat, 16 Jun 2012 17:16:34 +0200 Pacho Ramos > wrote: >> I can try to check it if no maintainer shows more packages >> showing this stable API unstable ABIs issues > > Please do. This is a fairly important point: if the number of > affected packages is small, there's no point in introducing > sub-slots. > I don't know about that -- I think we still very much need sub-slots. There is still a rather important distinction here -- SLOTS are currently used not to specify API, but to specify particular API groups that developers of said package are willing to support being installed (usually in parallel). For cases when developers decide it is not a good idea to support multiple APIs at a time (i go back to libpng here as an example of this current practice), 'SLOT=0' is still a valuable specification. Sub-slots will allow the actual API to be specified in this case (which as has been described will trigger rebuilds of consumers when necessary, if consumers *DEPEND on 'pkg:0=' or whatever the exact syntax will be) It's one thing for slot-operators in EAPI=5 to provide new tools to ensure better dependency handling; it's something else to assume the entire tree is going to be converted so that every package acting as a dependency will have a SLOT= reflecting the true API version rather than SLOT=0 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/fO/gACgkQ2ugaI38ACPBlNwD6Aw39lxsdGFSmHUqnzU+37A1P Z4x5TAtIrFsk7qK4y80A/RFpvD3J4YL8xonLKDWsey14BsKgq1Yz3VD5wlyDKJFd =FhFC -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Dynamic SLOTs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/06/12 11:53 AM, Michał Górny wrote: > On Sun, 17 Jun 2012 17:46:00 +0200 Thomas Sachau > wrote: >>> >>> ... If I weren't using 32-bit libs, and now I want to compile >>> 32-bit wine, I have to recompile most of my libraries for both >>> ABIs. That is a no go for me. >> >> So you want to build a 32bit package, which is depending on >> 32bit libs, but want to do that without the needed dependencies? >> Please tell me, how that works. > > I'm trying to build a 32bit package and its 32bit dependencies. > Your solution involves building a 32bit package and rebuilding all > 64bit packages which happen to be its dependencies for no reason. Wait, so a package will be re-emerged but only for the new ABI? So we're looking at partial package installing now? Or is this going to make multi-ABI installs be more like the way crossdev works, where each individual package supporting multiple ABIs will be installed multiple times, independently? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/fQAEACgkQ2ugaI38ACPCtFwD7BzuNxk00HgBfK5zd9dOwhcPw YJVvpXZR0AXtQyx46RQA/jR8Uqv1T99Tc+vhMWsGHLzfMDRR2DU8FlSFswQ2PG11 =eeDE -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On Mon, 18 Jun 2012 10:49:37 -0400 Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 17/06/12 11:53 AM, Michał Górny wrote: > > On Sun, 17 Jun 2012 17:46:00 +0200 Thomas Sachau > > wrote: > >>> > >>> ... If I weren't using 32-bit libs, and now I want to compile > >>> 32-bit wine, I have to recompile most of my libraries for both > >>> ABIs. That is a no go for me. > >> > >> So you want to build a 32bit package, which is depending on > >> 32bit libs, but want to do that without the needed dependencies? > >> Please tell me, how that works. > > > > I'm trying to build a 32bit package and its 32bit dependencies. > > Your solution involves building a 32bit package and rebuilding all > > 64bit packages which happen to be its dependencies for no reason. > > Wait, so a package will be re-emerged but only for the new ABI? So > we're looking at partial package installing now? Not exactly. Rather being able to build multiple packages from a single ebuild. > Or is this going to make multi-ABI installs be more like the way > crossdev works, where each individual package supporting multiple ABIs > will be installed multiple times, independently? Something like this, yet without writing additional ebuilds. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On Mon, Jun 18, 2012 at 10:34:44AM +0200, Micha?? G??rny wrote:
> On Sun, 17 Jun 2012 09:26:55 +0200
> Micha?? G??rny wrote:
>
> > I'm attaching a reStructuredText version of the spec. You can view it
> > rendered as a gist[1]. But please keep the replies on the list, rather
> > than forking the gist.
> >
> > [1]:https://gist.github.com/2943774
>
> Updated version. I've introduced dynamic SLOT groups and updated all
> relevant information.
>
> I didn't break DYNAMIC_SLOTS in ebuild to multiple variables yet but it
> will be easy to change that if necessary.
>
> This fixes problem previously described as 9a (dependencies). However,
> I've added a new issue, 10c which marienz pointed out.
Bleh; wish your attachment had been text/plain for inline
commenting; pardon any mangling...
> 3. Defining dynamic SLOT groups
> ---
>
> The list of supported dynamic SLOT groups should be declared
> in profile `make.defaults` as ``DYNAMIC_SLOT_GROUPS`` variable. That
> variable should contain whitespace-separated list of group names.
>
> For each group, the same file should have a variable named
> ``DYNAMIC_SLOTS_`` followed by the group name. That variable should list
> all possible dynamic SLOTs belonging to that group.
This is USE_EXPAND machinery; you should clarify why it's not being
reused here, nor treat explicitly as such.
Also, this gets fugly when one starts talking about individual pkgs
that have their own slotting, rather than global patterns like
python/multilib.
Should consider that and address it...
> 4. Defining supported SLOTs in an ebuild
>
>
> An ebuild supporting building for multiple dynamic SLOTs has to declare
> the supported slots using ``DYNAMIC_SLOTS`` variable. The variable can
> be inherited from eclasses.
>
> For example, an ebuild supporting building for multiple Python ABIs
> would declare (either explicitly or implicitly through an eclass)::
>
> DYNAMIC_SLOTS='py2.6 py2.7 py3.1 py3.2'
>
> which would mean that when the package is built, one of the ``pyX.Y``
> SLOTs must be used. As all of the listed SLOTs belong to the same group,
> only of them may be used at a time.
>
> An ebuild may also declare dynamic SLOTs from multiple groups::
>
> DYNAMIC_SLOTS='py2.6 py2.7 lib32 lib64'
>
> In this case, both one of ``pyX.Y`` and ``libX`` SLOTs need to be
> declared.
The words "I'll implement that when hell freezes over" come to
mind. That's a mess requiring the PM to know all potential values
and do interpolation on the fly; you're expecting the PM to be far,
far more intelligent then it can be, and the results won't be
pleasant (not counting the joys of writing such a resolver mind you).
Additionally, your notion breaks down if py3.3 supports lib64, but not
lib32.
If the groupings are treated as USE_EXPAND (even if a segregated group
of it), you can abuse the same REQUIRED_USE machinery to specify the
allowed pigeon holes/slots, including arbitrary group combinations.
Still will be a bit harsh for the resolver I expect, but that's at
least descriptive enough to handle the py3.3/lib64 scenario I
mentioned, while being explicit data the PM can operate on (local to
that ebuild) without having to do nastyness.
Note also that if one just dropped your notion of reinventing the
wheel, and reused REQUIRED_USE logic for slots... well, strikes me
that gives the flexibility you desire while folding it into existing
slot machinery. Haven't prototyped it, so may be cracktastic, but
seems a bit more integrated than what you're proposing.
> 5. Building the ebuild against chosen SLOTs
> ---
>
> In ``pkg_*`` and ``src_*`` phases, the build environment is provided
> with currently enabled dynamic SLOTs via variables named
> ``DYNAMIC_SLOT_`` followed by dynamic SLOT group name. The ebuild must
> use this variable to adjust the build process accordingly which can be
> done either directly or via an eclass.
>
> For example, in an ebuild using dynamic SLOTs for Python ABIs, the check
> may look like::
>
> case ${DYNAMIC_SLOT_PYTHON} in
> py2.6)
> # ...
> ;;
> py2.7)
> # ...
> ;;
> # ...
> esac
For ebuilds where one can't reuse the same source (moreso, can't do
the build of two different targets w/in that source, meaning you need
two work trees), this breaks down- which I expect is common. That
workflow needs to be non sucky for ebuild devs- so... sort that angle
please.
>
> 6. Relevance to binary and installed packages
> -
>
> It is necessary to store the dynamic SLOTs for which a package was built
> in the binary package and installed package metadata. The exact
> semantics are left to be implementation-specific. The implementation
> must ensure, however
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Sun, Jun 17, 2012 at 10:31:59PM +0200, Micha?? G??rny wrote: > Hello, > > A simple solution to a program long-unsolved. In GLEP form. > > Both attached and published as a gist: > > https://gist.github.com/2945569 > > (please note that github doesn't render GLEP headers correctly) > > -- > Best regards, > Micha?? G??rny > GLEP: XXX > Title: Optional runtime dependencies via runtime-switchable USE flags > Version: $Revision:$ > Last-Modified: $Date:$ > Author: Micha?? G??rny > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 17 Jun 2012 > Post-History: > > > Abstract > > > This GLEP addresses the issue of referencing optional runtime > dependencies in Gentoo packages and ebuilds. It does introduce > a concept of runtime-switchable USE flags to achieve that goal. > > > Motivation > == > > Optional runtime dependencies are often found in packages installing > various scripts (shell, python, perl). These are not strictly required > for the particular package to work but installing them enables > additional functionality. > > Unlike in compiled programs, enabling or disabling those features > (dependencies) does not affect the files installed by the package. > They can be installed and uninstalled independently of the package, > resulting in changes of functionality without a need to rebuild > the package. > > Currently such dependencies are usually expressed only through > ``pkg_postinst()`` messages. This forces user to manually install > the necessary dependencies, and uninstall them when they are no longer > necessary. > > Another solution is using regular USE flags. Those flags do not strictly > follow the principles of USE flags because they do not affect files > installed by the package and are not entirely effective to the package > (a disabled feature will still be available if necessary dependency is > installed). Additionally, it requires unnecessary rebuilds > of the package in order to change the dependencies. > > > Specification > = > > The ebuilds aiming to provide features enabled through optional runtime > dependencies should: > > 1. create regular USE flags for all those features, following >appropriate specifications for Gentoo ebuilds, and including >the flags in the ``IUSE`` variable; > 2. introduce additional ``IUSE_RUNTIME`` variable listing names of USE >flags related to optional runtime dependencies (without prefixes >related to IUSE defaults). > > Additionally, the ebuilds must obey the following rules: > > 1. all flags listed in ``IUSE_RUNTIME`` have to be listed in ``IUSE``, > 2. flags listed in ``IUSE_RUNTIME`` can be referred in ``RDEPEND``, >``PDEPEND`` and ``REQUIRED_USE`` variables, > 3. flags listed in ``IUSE_RUNTIME`` must not be referred in phase >functions, ``DEPEND`` or ``SRC_URI``, > 4. flags listed in ``IUSE_RUNTIME`` may be referred through USE >dependencies by other packages' ``DEPEND``, ``RDEPEND`` >and ``PDEPEND`` variables. Unless I'm on crack, you're stating that essentially an optional use flag (one you label 'runtime'), is able to be used transitively during DEPEND. That's not particularly "here's some suggested pkgs to install"- that's "rebuild the fucker for this changed DEPEND", which is the existing situation. > The package manager should treat flags listed in ``IUSE_RUNTIME`` > as regular USE flags, except for the following: > > 1. the state of the flags must be re-evaluated each time the package >dependency graph is considered, > 2. enabling or disabling any of the flags must not involve rebuilding >the package, > 3. the flags may be listed in the visual output in a distinct way >to inform the user that they affect runtime dependencies only. > > > Rationale > = > > The proposed solution tries to solve the issue of handling runtime > dependencies while reusing the existing infrastructure. Most > importantly, users will be able to reuse the existing tools > and configuration files to enable and disable optional runtime > and build-time dependencies alike. > > The remaining reused features include: > > - dependency syntax, If you invent new syntax, I'm going to be unhappy. KISS as it were. > - ability to use ``REQUIRED_USE``, USE dependencies, > - ability to describe flags in `metadata.xml`, > - global flag names (and descriptions). > > Alternative proposed solution involved creating additional ``SDEPEND`` > variable. That proposition had the following disadvantages: > > - being package-oriented rather than feature-oriented, No; use flags are our configuration space, and they turn on/off sections of the given pkgs graph. Your proposal relies on the same concept; bluntly, what you're proposing is just as 'package oriented'. Effectively, you can't dismiss SDEPEND/ODEPEND via changing the rules between your proposal and ODEPEND's proposal. Nice try though. :) > - lack of ability to express multiple package
[gentoo-dev] New global USE flag "id3tag"
id3tag: Enable support for ID3 metadata Current consumers: USE="id3tag": media-sound/alsaplayer: Enables ID3 tagging with id3tag library media-sound/audacity: Enables ID3 tagging with id3tag library media-sound/mpd: Support for ID3 tags media-sound/sonic-visualiser: Enables ID3 tagging with id3tag library media-sound/sox: Enables ID3 tagging with id3tag library media-video/vlc: Enables id3tag metadata reader plugin. USE="id3" which will be renamed to USE="id3tag" wrt #421873: media-sound/abcde: Support ID3, ID3v2 tagging of audio files
