Re: Can/should we have an efi/efi-any platform architecture?
On Thu, Dec 11, 2014 at 08:49:55PM +, Simon McVittie wrote: On 11/12/14 18:08, Leif Lindholm wrote: The point is, when we add support for another architecture which supports UEFI, there are a number of packages that you will want to enable for that architecture. I've occasionally wished we had a way to make a requiring package conditionally built depending on availability of another package, usually an interpreter that needs explicit porting. For instance: * dbus should ideally Build-Depends: valgrind on precisely those architectures where valgrind exists * C# bindings should ideally be built on precisely those architectures where mono exists * Java bindings should ideally be built on precisely those architectures where openjdk exists There is a slightly ugly technique, that achieves what you want without build profiles or any recently added functionality. Considering the valgrind example: * Have valgrind Provides: optional-valgrind * Add a new binary package no-valgrind to the valgrind source package. It also Provides: optional-valgrind. This new package is only built for architectures where valgrind is not built. Now dbus can Build-Depends: optional-valgrind. As the architecture field does not allow negated architectures, a clear downside is that now you have to maintain two architecture sets for valgrind. So when e.g. or1k comes along you will have to add it to either valgrind or no-valgrind. Still the tradeoff seems to be good as soon as optional-valgrind collects a handful reverse dependencies. What do you think? Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141217084500.ga16...@alf.mars
Re: Using build profiles beyond bootstrappingcross (was: Re: Can/should we have an efi/efi-any platform architecture?)
Hello, On 12 December 2014 at 11:48, Johannes Schauer j.scha...@email.de wrote: Hi, Quoting Simon McVittie (2014-12-12 12:09:05) Yes, but I think that's exactly what I want for dbus' use-case? I want to build-depend on valgrind (I thought it was valgrind-dev, but it's actually valgrind) on exactly those architectures to which valgrind has been ported, so that the debug flavour of libdbus can have its optional valgrind instrumentation on those architectures; but on architectures to which valgrind has not yet been ported, dbus still needs to produce working binaries. Some packages solve this by copying (a random snapshot of) the valgrind headers into their source code, but I'd prefer to minimize the number of embedded code copies. At the moment that's: Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64 s390x], ... which is an inconvenient amount of hard-coding, and has led to one RC bug already (when valgrind dropped support for armel). With build profiles (which I'll reinstate in unstable when jessie becomes stable) it would be something like: Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64 s390x] !stage1, ... but I'd rather have Build-Depends: ..., valgrind arch-where-valgrind-exists !stage1, ... or whatever spelling. okay. I get you now. Debian build profiles can express what USE flags do for Gentoo. What you probably want is: Build-Depends: ..., valgrind !without-valgrind, ... snip unlike Simon, I would tend to agree that we do want this. It's indeed not quite USE flags, but rather encoding per-arch default build dependencies. E.g. the way we encode default MPI per-arch implementation, default Java per-arch implementation and etc. However, this would imply to maintain default set of per-arch profiles somewhere, update them, and always use them. And secondly, I like that build-profiles can be used in a standard fashion to support non-free configurations of rebuilding main packages, aka with-openssl. But this use case is supportable with existing profile implementation. Thirdly I expect that we want default vendor profiles to exist. E.g. a lot of delta between ubuntu debian can go away / incorporated in debian source packages if maintainers agree to merge something like foo !vendor-ubuntu (boost, e2fsprogs, zsh packages come to mind among others). -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhlug_5yhspsbthrbhrm4eofzyepvap9md9wuvqexzty5...@mail.gmail.com
Re: Can/should we have an efi/efi-any platform architecture?
Quoting Joachim Breitner (2014-12-12 13:55:24) Am Freitag, den 12.12.2014, 12:07 + schrieb Wookey: +++ Sebastian Reichel [2014-12-11 21:25 +0100]: How about building for arch: any and adding a build dependency on a new efi-support package, that is only available for architectures with efi available? I was about to suggest the same thing. That is a sensible suggestion. It keeps the ecosystem of 'efi stuff' more self-contained than involving dpkg. If it was expected to change frequently this would probably work better in practice. that’s what the Haskell packages to. Some require a certain feature that is not available on all arches, and a virtual packages provided only on those arches (ghc-ghci) is used in the Build-Depends. Works great, and once a new architecture gets added, all packages are automatically built. Are those features tied to hardware? Could you provide some examples? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Can/should we have an efi/efi-any platform architecture?
Leif Lindholm leif.lindh...@linaro.org (2014-12-11): The point is, when we add support for another architecture which supports UEFI, there are a number of packages that you will want to enable for that architecture. Currently, this means trawling through all of the packages and explicitly adding entries for If we could transition this to be able to specify efi-all (or whatever) instead of an explicit list of certain architectures, this would be a lot more straightforward operation. I can understand the feeling, having done such things in different areas (non-Linux porting, I was young…), but it seems to me the best way to deal with that is to just list the relevant packages on some wiki page. It's not like we're adding new architectures every month, and some one-shot updates of well-known components shouldn't be too much of a hassle. You're likely going to need and double check there's no missing arch-specific bits anyway, see 2c62dc1542bb8d67da97de40a5d9c7da645fa498 in grub-installer for a random example. So said wiki page would probably benefit from some per-package “how to add support for a new arch” instructions. An alternative would of course be to simply do like with acpica-tools, and build all of these tools for all architectures. The problem there would be with packages which depend on packages that only exist on architectures that have UEFI - i.e. partman-efi vs. efi-modules. efi-modules (is virtual but anyway) is section: debian-installer, so is in another part of the repository, that wanna-build and friends doesn't known about (at least that'd be my guess). Mraw, KiBi. signature.asc Description: Digital signature
Re: Can/should we have an efi/efi-any platform architecture?
Hi, Quoting Simon McVittie (2014-12-11 21:49:55) At a source package granularity, you can fake it by having a (possibly spurious) Build-Depends on the required package, which will put the requiring package in BD-Uninstallable state (e.g. https://buildd.debian.org/status/package.php?p=gtk-sharp3 explains why gtk-sharp3 isn't built on mips, which doesn't have mono). Either please don't add known-unused build dependencies as this will just make the dependency graph bigger and life for bootstrappers harder or, once jessie is released, if you feel you must, then add them with a !stage1 (or similar - not sure what would best apply here) build profiles restriction. That doesn't work for individual binary packages unless you hard-code architecture lists, though (e.g. a C library with an optional Java or C# binding would need to hard-code the Java/C# architectures). Perhaps this could be a build-profile? Source: dbus Build-Depends: ..., valgrind-dev archfeature.valgrind, ... Source: libfoo ... Package: libfoo-sharp Architecture: any Build-Profiles: archfeature.mono Firstly, the build profile spec was revised during the bootstrap sprint in Paris and what will end up in Jessie now does not have namespaces anymore. The reasoning is fully explained in the sprint result email section 6.2: https://lists.debian.org/debian-devel-announce/2014/08/msg00013.html Maybe we could even use package names as the features, so each feature in the archfeature namespace is automatically said to be available iff the package exists in apt? That covers the common interpreter that needs porting case, although I don't know whether there's anything like an efi-dev that could act as the flag for EFI architectures. Other possible colours for this bike shed include pkgexists.valgrind, with.valgrind, or (with the opposite sense) without.valgrind, missing.valgrind. Secondly, what you are expressing with: valgrind-dev archfeature.valgrind is that you do or do not depend on the package valgrind-dev depending on whether or not archfeature.valgrind evaluates to true (however this is resolved). Build profiles are NOT meant for tagging purposes but for conditional selection of build dependencies. The disjunctive normal form expression of build profiles does not make sense for tagging purposes as needed for this use case (archfeature.valgrind is used like a tag that adds meaning to the build dependency valgrind-dev). For this reason I don't think that build profiles will solve this problem. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212104050.15300.84986@hoothoot
Re: Can/should we have an efi/efi-any platform architecture?
On 12/12/14 10:40, Johannes Schauer wrote: Secondly, what you are expressing with: valgrind-dev archfeature.valgrind is that you do or do not depend on the package valgrind-dev depending on whether or not archfeature.valgrind evaluates to true (however this is resolved). Yes, but I think that's exactly what I want for dbus' use-case? I want to build-depend on valgrind (I thought it was valgrind-dev, but it's actually valgrind) on exactly those architectures to which valgrind has been ported, so that the debug flavour of libdbus can have its optional valgrind instrumentation on those architectures; but on architectures to which valgrind has not yet been ported, dbus still needs to produce working binaries. Some packages solve this by copying (a random snapshot of) the valgrind headers into their source code, but I'd prefer to minimize the number of embedded code copies. At the moment that's: Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64 s390x], ... which is an inconvenient amount of hard-coding, and has led to one RC bug already (when valgrind dropped support for armel). With build profiles (which I'll reinstate in unstable when jessie becomes stable) it would be something like: Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64 s390x] !stage1, ... but I'd rather have Build-Depends: ..., valgrind arch-where-valgrind-exists !stage1, ... or whatever spelling. Similarly, db5.3 has Build-Depends: ..., default-jdk [!m68k], ... (and other Java things on [!m68k]) and gdcm has Build-Depends: ..., cli-common-dev (= 0.8~) [amd64 armel i386 kfreebsd-amd64 kfreebsd-i386 powerpc ppc64 s390x], ... (and other Mono things on those architectures) but there'd be no need for the Java and Mono maintainers to coordinate these ad-hoc architecture lists with other maintainers via bugs like #719842, #575138, #541612, #477855, #699379, #657779 if packages like db5.3 and gdcm could instead say: Build-Depends: ..., default-jdk arch-where-java-exists, ... Build-Depends: ..., cli-common-dev arch-where-mono-exists, ... Regards, S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/548accd1.6070...@debian.org
Re: Can/should we have an efi/efi-any platform architecture?
Hi, Quoting Dimitri John Ledkov (2014-12-11 22:28:07) And it will require a long time to be used. Imho this smells more like a build profile e.g. BuildDepends: does-not-implement-efi !efi That way on non-efi implementing architectures the package will get stuck in a dep-wait state. I wouldn't say it smells like a use for build profiles because it would require builders to set the DEB_BUILD_PROFILES variable on known architectures. Depending on whether or not you see it as one, this might open a can of worms because this technique could then be abused for other non-efi source packages which should also only be built on a certain set of architectures. This in turn will increase the amount of existing build profile names which is currently a well defined set of cardinality six. Depending on whether or not you want Debian to use build profiles more like Gentoo USE flags (Debian build profiles are equally powerful in what they allow to express) instead of limiting build profiles to special situations like bootstrapping or cross building, this increase of build profile names might be a good or a bad thing. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014121232.15300.26065@hoothoot
Re: Can/should we have an efi/efi-any platform architecture?
On 12/12/14 11:09, Simon McVittie wrote: but I'd rather have Build-Depends: ..., valgrind arch-where-valgrind-exists !stage1, ... Looking at BuildProfileSpec again, that would actually have to be valgrind arch-where-valgrind-exists !stage1 to express (arch-where-valgrind-exists !stage1). The idea is the same though. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/548acf06.5050...@debian.org
Using build profiles beyond bootstrappingcross (was: Re: Can/should we have an efi/efi-any platform architecture?)
Hi, Quoting Simon McVittie (2014-12-12 12:09:05) Yes, but I think that's exactly what I want for dbus' use-case? I want to build-depend on valgrind (I thought it was valgrind-dev, but it's actually valgrind) on exactly those architectures to which valgrind has been ported, so that the debug flavour of libdbus can have its optional valgrind instrumentation on those architectures; but on architectures to which valgrind has not yet been ported, dbus still needs to produce working binaries. Some packages solve this by copying (a random snapshot of) the valgrind headers into their source code, but I'd prefer to minimize the number of embedded code copies. At the moment that's: Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64 s390x], ... which is an inconvenient amount of hard-coding, and has led to one RC bug already (when valgrind dropped support for armel). With build profiles (which I'll reinstate in unstable when jessie becomes stable) it would be something like: Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64 s390x] !stage1, ... but I'd rather have Build-Depends: ..., valgrind arch-where-valgrind-exists !stage1, ... or whatever spelling. okay. I get you now. Debian build profiles can express what USE flags do for Gentoo. What you probably want is: Build-Depends: ..., valgrind !without-valgrind, ... No need for the !stage1 because you will probably have the without-valgrind build profile activated during a bootstrap unless you already have valgrind. Then buildds could set DEB_BUILD_PROFILES=without-valgrind on architectures without valgrind. Whether you call it valgrind or without-valgrind depends on what you want the default to be. In this regard, Debian build profiles work opposite to Gentoo USE flags. By default, no build profile is active which in Debian means: build everything with all features active. If no USE flag is enabled in Gentoo you get a very minimal build. Thus, if you want the default build to build *with* valgrind, then your profile should be named without-valgrind and only be set when you want to build without it (for example during bootstrapping or on architectures that don't have valgrind). Similarly, db5.3 has Build-Depends: ..., default-jdk [!m68k], ... (and other Java things on [!m68k]) and gdcm has Build-Depends: ..., cli-common-dev (= 0.8~) [amd64 armel i386 kfreebsd-amd64 kfreebsd-i386 powerpc ppc64 s390x], ... (and other Mono things on those architectures) but there'd be no need for the Java and Mono maintainers to coordinate these ad-hoc architecture lists with other maintainers via bugs like #719842, #575138, #541612, #477855, #699379, #657779 if packages like db5.3 and gdcm could instead say: Build-Depends: ..., default-jdk arch-where-java-exists, ... Build-Depends: ..., cli-common-dev arch-where-mono-exists, ... It is entirely possible to add build profile names for a bunch of stuff like valgrind, java and mono (they would probably just be called without-valgrind, without-java and without-mono - or s/without/no/). The question is, whether the Debian project wants to extend build profiles beyond it's current limited use for bootstrapping and cross building and thus make them more like Gentoo USE flags? This also means that if somebody builds the package locally on an architecture without valgrind, for example, then they must not forget to without-valgrind build profile or they will trigger a FTBFS. Thus it probably makes more sense to let the list of profiles that are active by default be stored somewhere on the system (which is also how it's done in Gentoo for USE flags). A good place for such a hypothetical list is probably dpkg. In that case, the buildds would also not need to do anything special when building. Should that be done, it probably also makes sense to add a facility to overwrite the default. In Gentoo they prefix a minus. In Debian, the most logical syntax would probably be the exclamation mark. So to enable valgrind on an architecture that doesn't have it would then be like: DEB_BUILD_PROFILES=!without-valgrind dpkg-buildpackage or dpkg-buildpckage -P!without-valgrind You could then even go one step further and say: if dpkg stores a list of build profiles that are activated by default on an architecture, then the default list of active build profiles is not empty and there is no need to have a without-valgrind profile because the valgrind profile could be active by default on architectures with valgrind. This would make it quite a bit more readable and even more similar to Gentoo :P Thoughts? cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212114840.15300.27739@hoothoot
Re: Can/should we have an efi/efi-any platform architecture?
+++ Jonas Smedegaard [2014-12-11 21:38 +0100]: Quoting Neil Williams (2014-12-11 21:07:15) On Thu, 11 Dec 2014 19:36:19 +0100 Simon Richter s...@debian.org wrote: On 11.12.2014 19:08, Leif Lindholm wrote: If we could transition this to be able to specify efi-all (or whatever) instead of an explicit list of certain architectures, this would be a lot more straightforward operation. Useful, possibly, but there is no mechanism that could be used or recycled for that, so it would be an entirely new mechanism in the package management framework, with a fairly limited use case. There is an accepted mechanism: linux-any is a group of architectures which have one set of packages in common and we have had others. efi-any would seem to be entirely possible without implementing something completely new. It would need dpkg and buildd support. With linux-any it relies on a list of architectures in a table in dpkg - the same could be done for other groups. Elegant! This was the mechanism the original mail was intended to consider. (We already discussed this in the office). The question is: is a simple grouping of existing architecture sufficient for this sort of case. Support for this is just added in dpkg - that's very simple. I guess some other things like lintian would need to know about it being a valid value. The effect of marking a package efi-any is that it is always built on the architectures so-marked. That means that it is available on those arches, for hardware that supports efi. The tricky bits comes around the fact that at any given time some hardware in an arch is efi, some is not. So building the package on those arches (and marking it 'efi-any') does not mean that efi is always available, on a given machine, just that it might be. This has been the case in x86 (and presumably other arches) for a long time and works fine. I _think_ this is absolutely fine, and actually this mechanism fits very well for this purpose. But it is still a new usage of our 'arch-grouping' mechanism, and some thought about what might go wrong is in order. The alternative to having this sort of 'sub-platform available on this arch' name is to manage the arches manually in all the affected packages, which is mostly a porter job (rather than a maintainer job) as they know when efi appears on new arches. That's clearly do-able, having been the mechanism to-date. And it remains an option as packages can still give an explicit list if they like - they don't _have_ to declare 'I should build on everything 'efi-any'. Putting this info in dpkg means that it can only be updated quite slowly, but new efi arches do not come along very often, so I think that will work OK in practice. So I am a little wary, but I _think_ this makes quite a lot of sense. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212114907.gf27...@stoneboat.aleph1.co.uk
Re: Can/should we have an efi/efi-any platform architecture?
+++ Sebastian Reichel [2014-12-11 21:25 +0100]: Hi, How about building for arch: any and adding a build dependency on a new efi-support package, that is only available for architectures with efi available? That is a sensible suggestion. It keeps the ecosystem of 'efi stuff' more self-contained than involving dpkg. If it was expected to change frequently this would probably work better in practice. However it does leave the depending packages listed as 'BD-uninstallable' on the non-efi architectures, which gives the impression that one day they _should_ appear, which is not really the case here. efi-any (as an architecture group) would correctly list things as 'not-for-us' on the unsupported architecture. Not a huge practical difference, but suggests to me that efi-any as an architecture-group is a better fit. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212120723.gg27...@stoneboat.aleph1.co.uk
Re: Can/should we have an efi/efi-any platform architecture?
Hi, Am Freitag, den 12.12.2014, 12:07 + schrieb Wookey: +++ Sebastian Reichel [2014-12-11 21:25 +0100]: How about building for arch: any and adding a build dependency on a new efi-support package, that is only available for architectures with efi available? I was about to suggest the same thing. That is a sensible suggestion. It keeps the ecosystem of 'efi stuff' more self-contained than involving dpkg. If it was expected to change frequently this would probably work better in practice. that’s what the Haskell packages to. Some require a certain feature that is not available on all arches, and a virtual packages provided only on those arches (ghc-ghci) is used in the Build-Depends. Works great, and once a new architecture gets added, all packages are automatically built. However it does leave the depending packages listed as 'BD-uninstallable' on the non-efi architectures, which gives the impression that one day they _should_ appear, which is not really the case here. True, but so far did not bother a lot of people. So given that there is precedence, I suggest this route rather than touching dpkg for this. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Can/should we have an efi/efi-any platform architecture?
When working on UEFI kernel support, for both armhf and arm64, we came across packages (in several distributions) that were manually set to build for architectures where UEFI was available - and so would not be built for the ARM architectures. These are some obvious utilites such as: - efibootmgr - efivar/libefivar - future versions of gnu-efi (upstream support for arm* has not trickled back down yet) But also installer-specific ones like: - partman-efi And some weakly related-to, but not really part of: - dmidecode ... and definitely other ones I haven't come across yet. The point is, when we add support for another architecture which supports UEFI, there are a number of packages that you will want to enable for that architecture. Currently, this means trawling through all of the packages and explicitly adding entries for If we could transition this to be able to specify efi-all (or whatever) instead of an explicit list of certain architectures, this would be a lot more straightforward operation. Most, if not all, of these tools use only standard posix interfaces, so will build cleanly for any architecture. An alternative would of course be to simply do like with acpica-tools, and build all of these tools for all architectures. The problem there would be with packages which depend on packages that only exist on architectures that have UEFI - i.e. partman-efi vs. efi-modules. Would this be useful, desirable, an accident waiting to happen? / Leif -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141211180858.gs2...@bivouac.eciton.net
Re: Can/should we have an efi/efi-any platform architecture?
Hi Leif, On 11.12.2014 19:08, Leif Lindholm wrote: If we could transition this to be able to specify efi-all (or whatever) instead of an explicit list of certain architectures, this would be a lot more straightforward operation. Would this be useful, desirable, an accident waiting to happen? Useful, possibly, but there is no mechanism that could be used or recycled for that, so it would be an entirely new mechanism in the package management framework, with a fairly limited use case. As this is something that changes rather seldom, I think it would be overkill. Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5489e423.8090...@debian.org
Re: Can/should we have an efi/efi-any platform architecture?
Simon Richter wrote: Hi Leif, On 11.12.2014 19:08, Leif Lindholm wrote: If we could transition this to be able to specify efi-all (or whatever) instead of an explicit list of certain architectures, this would be a lot more straightforward operation. Would this be useful, desirable, an accident waiting to happen? Useful, possibly, but there is no mechanism that could be used or recycled for that, so it would be an entirely new mechanism in the package management framework, with a fairly limited use case. As this is something that changes rather seldom, I think it would be overkill. Hmmm, maybe. EFI is a bit of a special case in several respects - in some places in Debian (e.g. d-i) it's treated like a sub-architecture. But it's a common sub-architecture across several architectures, which is very different to m68k/atari and the like. On a related front... see other mail. -- Steve McIntyre, Cambridge, UK.st...@einval.com ...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver. -- Daniel Pead -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xz8pq-0004t6...@mail.einval.com
Re: Can/should we have an efi/efi-any platform architecture?
Quoting Simon Richter (2014-12-11 19:36:19) On 11.12.2014 19:08, Leif Lindholm wrote: If we could transition this to be able to specify efi-all (or whatever) instead of an explicit list of certain architectures, this would be a lot more straightforward operation. Would this be useful, desirable, an accident waiting to happen? Useful, possibly, but there is no mechanism that could be used or recycled for that, so it would be an entirely new mechanism in the package management framework, with a fairly limited use case. As this is something that changes rather seldom, I think it would be overkill. Perhaps if framing it more generally instead, it would be relevant to work on. How about a control file hint Arch-Varying: listing features known to be crippled for some of the archs they are actually compiled on? Example that popped up recentently is VLC which upstream supports OSS as fallback for ALSA, and (as I understand it) for Debian is built _without_ support for OSS on Linux archs where ALSA is generally (but possibly not for all use cases) superior. I imagine vlc could be tagged as Arch-Varying: alsa oss ...where the alsa hint can be expected for any package supporting alsa but working to some degree without it, whereas the oss hint for some would be a reason to inspect closer (e.g. check README file for details). To minimize creativity in feature naming we could put names up on a wiki page, and later if/when gaining traction move that to Policy. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Can/should we have an efi/efi-any platform architecture?
On Thu, 11 Dec 2014 19:36:19 +0100 Simon Richter s...@debian.org wrote: Hi Leif, On 11.12.2014 19:08, Leif Lindholm wrote: If we could transition this to be able to specify efi-all (or whatever) instead of an explicit list of certain architectures, this would be a lot more straightforward operation. Would this be useful, desirable, an accident waiting to happen? Useful, possibly, but there is no mechanism that could be used or recycled for that, so it would be an entirely new mechanism in the package management framework, with a fairly limited use case. There is an accepted mechanism: linux-any is a group of architectures which have one set of packages in common and we have had others. efi-any would seem to be entirely possible without implementing something completely new. It would need dpkg and buildd support. With linux-any it relies on a list of architectures in a table in dpkg - the same could be done for other groups. The mechanisms exist, the question is how many other variants would be created by adopting this? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpaT0kgbPNR0.pgp Description: OpenPGP digital signature
Re: Can/should we have an efi/efi-any platform architecture?
Hi, On Thu, Dec 11, 2014 at 06:08:58PM +, Leif Lindholm wrote: When working on UEFI kernel support, for both armhf and arm64, we came across packages (in several distributions) that were manually set to build for architectures where UEFI was available - and so would not be built for the ARM architectures. These are some obvious utilites such as: - efibootmgr - efivar/libefivar - future versions of gnu-efi (upstream support for arm* has not trickled back down yet) But also installer-specific ones like: - partman-efi And some weakly related-to, but not really part of: - dmidecode ... and definitely other ones I haven't come across yet. The point is, when we add support for another architecture which supports UEFI, there are a number of packages that you will want to enable for that architecture. Currently, this means trawling through all of the packages and explicitly adding entries for If we could transition this to be able to specify efi-all (or whatever) instead of an explicit list of certain architectures, this would be a lot more straightforward operation. Most, if not all, of these tools use only standard posix interfaces, so will build cleanly for any architecture. An alternative would of course be to simply do like with acpica-tools, and build all of these tools for all architectures. The problem there would be with packages which depend on packages that only exist on architectures that have UEFI - i.e. partman-efi vs. efi-modules. Would this be useful, desirable, an accident waiting to happen? How about building for arch: any and adding a build dependency on a new efi-support package, that is only available for architectures with efi available? -- Sebastian signature.asc Description: Digital signature
Re: Can/should we have an efi/efi-any platform architecture?
Quoting Neil Williams (2014-12-11 21:07:15) On Thu, 11 Dec 2014 19:36:19 +0100 Simon Richter s...@debian.org wrote: On 11.12.2014 19:08, Leif Lindholm wrote: If we could transition this to be able to specify efi-all (or whatever) instead of an explicit list of certain architectures, this would be a lot more straightforward operation. Would this be useful, desirable, an accident waiting to happen? Useful, possibly, but there is no mechanism that could be used or recycled for that, so it would be an entirely new mechanism in the package management framework, with a fairly limited use case. There is an accepted mechanism: linux-any is a group of architectures which have one set of packages in common and we have had others. efi-any would seem to be entirely possible without implementing something completely new. It would need dpkg and buildd support. With linux-any it relies on a list of architectures in a table in dpkg - the same could be done for other groups. Elegant! The mechanisms exist, the question is how many other variants would be created by adopting this? Please ignore my use cases - they were about features enabled/disabled rather than architectures targeted at all, which is what Leif asks for. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Can/should we have an efi/efi-any platform architecture?
On 11/12/14 18:08, Leif Lindholm wrote: The point is, when we add support for another architecture which supports UEFI, there are a number of packages that you will want to enable for that architecture. I've occasionally wished we had a way to make a requiring package conditionally built depending on availability of another package, usually an interpreter that needs explicit porting. For instance: * dbus should ideally Build-Depends: valgrind on precisely those architectures where valgrind exists * C# bindings should ideally be built on precisely those architectures where mono exists * Java bindings should ideally be built on precisely those architectures where openjdk exists At a source package granularity, you can fake it by having a (possibly spurious) Build-Depends on the required package, which will put the requiring package in BD-Uninstallable state (e.g. https://buildd.debian.org/status/package.php?p=gtk-sharp3 explains why gtk-sharp3 isn't built on mips, which doesn't have mono). That doesn't work for individual binary packages unless you hard-code architecture lists, though (e.g. a C library with an optional Java or C# binding would need to hard-code the Java/C# architectures). Perhaps this could be a build-profile? Source: dbus Build-Depends: ..., valgrind-dev archfeature.valgrind, ... Source: libfoo ... Package: libfoo-sharp Architecture: any Build-Profiles: archfeature.mono Maybe we could even use package names as the features, so each feature in the archfeature namespace is automatically said to be available iff the package exists in apt? That covers the common interpreter that needs porting case, although I don't know whether there's anything like an efi-dev that could act as the flag for EFI architectures. Other possible colours for this bike shed include pkgexists.valgrind, with.valgrind, or (with the opposite sense) without.valgrind, missing.valgrind. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/548a0373.2030...@debian.org
Re: Can/should we have an efi/efi-any platform architecture?
On 11 December 2014 at 20:07, Neil Williams codeh...@debian.org wrote: On Thu, 11 Dec 2014 19:36:19 +0100 Simon Richter s...@debian.org wrote: Hi Leif, On 11.12.2014 19:08, Leif Lindholm wrote: If we could transition this to be able to specify efi-all (or whatever) instead of an explicit list of certain architectures, this would be a lot more straightforward operation. Would this be useful, desirable, an accident waiting to happen? Useful, possibly, but there is no mechanism that could be used or recycled for that, so it would be an entirely new mechanism in the package management framework, with a fairly limited use case. There is an accepted mechanism: linux-any is a group of architectures which have one set of packages in common and we have had others. efi-any would seem to be entirely possible without implementing something completely new. It would need dpkg and buildd support. With linux-any it relies on a list of architectures in a table in dpkg - the same could be done for other groups. The mechanisms exist, the question is how many other variants would be created by adopting this? And it will require a long time to be used. Imho this smells more like a build profile e.g. BuildDepends: does-not-implement-efi !efi That way on non-efi implementing architectures the package will get stuck in a dep-wait state. However, EFI is not that simple as it has it's own architecture mapping, it's own binary format and execution environment, but it is unlikely that we will see debian ported to be run in pure EFI environment. EFI is currently defined for IA32, X64, IA64, ARM, and AA64. However in practice the support implementing it is ahead on X64 (despite IA64 being the first one). E.g. even things like edk2 - i've tried to compile it for IA32 but appears to be only partially implemented for gcc toolchain. Thus even if something is efi-ish and should build for all efi-like-arches it doesn't mean that it was ported or builds with efi toolchain. For some of these things we are stepping into crazy land of ia32-libs territory where we are considering to introduce and install grub-ia32 grub-x64 on amd64 systems. IMHO it would be cool to compile gnu-efi, grub, etc as gnu-efi:efi-ia32, gnu-efi:efi-x64 etc. packages and have generic mapping somewhere between debian architectures efi architectures and install those things as appropriate. That would be a partial arch. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhlugatff2szaxd+m8nk-k0tb-t7jhhfmickgrcuj_is8...@mail.gmail.com
