[gentoo-dev] News Item: LastPass package migration - v2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Here's the version 2 with the fixed author information. I forgot to send the initial email to the PR team, so doing that now. Will commit in 72 hours if there are no objections. - -- Title: LastPass package migration Author: Göktürk Yüksek Author: Robin H. Johnson Content-Type: text/plain Posted: 2016-05-15 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: app-admin/lastpass LastPass-3 and earlier versions installed browser extensions along with the necessary binary components. LastPass-4 and later versions install only the binary components and leave installing the browser extensions to the user. Furthermore, LastPass-3 is not available anymore, it will be removed soon and users are required to upgrade. A transparent package move is not possible due to the mentioned changes and a manual migration is required. The currently installed package must be removed before proceeding with the migration: emerge --unmerge --ask app-admin/lastpass LastPass for Firefox users can safely upgrade to version 4 by visiting the official LastPass website and following the download instructions. The browser extension already contains the required binary components. No packages need to be installed. Users of Chrome/Chromium and Opera browsers need to switch to app-admin/lastpass-binary-features and follow the instructions displayed on the screen after the installation to complete the process. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXPpz0AAoJEIT4AuXAiM4zZyMH/RX2ISvUhW4DRE0Ntq+k4CHY Oe7NNvNprEPxECkn1TiD/NsP0jEGjXS5SFA3jvu11c9dalnXtQ/SrBiTOI24NPj4 74/2gDzgJEYvDxIc2USCOxs2QXaB9L08n1MIFu4fACkqSR4wnJrR+ggq6BkMrY/J ga9XIVEOjbA9XfcHplBLZ+1vlcZCB6rYK5i8EyB/Slp6lDw4MZ1M63aF3O2nON8W B7EmZ4EjR7sWjnWnHevvwXJ82xpGlYr4bgJhITJ55s9wbohcavsDyFZTj/GudZDl NUytv8UVPtZp6PWqfBhPpLmts3SQFzhGNunHCm8Gmurcv7paQJgF1MApM9NZ4Fg= =bSjH -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: bugfix for get-flag()
On 16 May 2016 14:17, rindeal wrote:
> So this is what it looks like now:
still missing tests. see eclass/tests/flag-o-matic.sh.
> - local f var findflag="$1"
> -
> - # this code looks a little flaky but seems to work for
> - # everything we want ...
> - # for example, if CFLAGS="-march=i686":
> - # `get-flag -march` == "-march=i686"
> - # `get-flag march` == "i686"
> + local var pattern="${1}"
drop the braces for builtin vars
> for var in $(all-flag-vars) ; do
> - for f in ${!var} ; do
> - if [ "${f/${findflag}}" != "${f}" ] ; then
> - printf "%s\n" "${f/-${findflag}=}"
> + local i flags=( ${!var} )
> + for (( i=${#flags[@]}-1; i>=0; i-- )) ; do
omitting spaces doesn't make code faster, it just makes it unreadable.
for (( i = ${#flags[@]} - 1; i >= 0; --i )) ; do
stick a comment above this for loop explaining why we walk backwards.
> + local needle="-${pattern#-}" # force dash on
avoid inline comments and make them complete sentences.
# Make sure we anchor to the leading dash.
local needle="-${pattern#-}"
> + local haystack="${flags[i]%%=*}" # we're comparing flags, not
> values
it's a bit easier to read if you unpack the flag explicitly.
local flag=${flags[i]}
> + if [[ ${haystack##${needle}} == '' ]] ; then
use a -z test instead of comparing to ''
-mike
signature.asc
Description: Digital signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
On 18 May 2016 22:25, aide...@gentoo.org wrote: > awk doesn't have the -i option like sed and if editing file in place is > desired, additional steps are required. eawk uses tmp file to make it > look to the caller editing happens in place. what's your real use case ? i've never once thought "man, i wish i could run an awk script and modify a file in place". and i write awk most days. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
On 20 May 2016 02:16, Mart Raudsepp wrote: > I would like if such a function would explicitly document that calling > this function means the caller should DEPEND on an awk provider. > Similarly, I would like that all ebuild that call 'sed' actually DEPEND > on sed, not just half of them. > I would also like that no ebuild would assume packages in @system to be > present, beyond those dictated by PMS (unpackers and such). this is all a terrible terrible idea and has been hashed/explained a number of times on this list. have you ever tried looking at the tools configure scripts run ? -mike signature.asc Description: Digital signature
Re: [gentoo-dev] new developers' keyword requests
On 05/19/2016 07:51 AM, Jeroen Roovers wrote: > Perhaps it's a good idea to add a section to the devmanual about adding > new keywords to packages. > > Recruits in particular might benefit from some background on what > keywording means and when it should be done, especially before they > start maintaining packages and then realise their packages are so > beautiful that they positively *deserve* to have some random keywords > added. This is not productive. > > The way it works is that users of > specific architectures find that a package works for them on their > systems (which have enough resources and have the correct interfaces for > that particular program to be used conveniently, and so on), and that > they then request that their architecture keyword be added. What > doesn't work is having a handful of keywords on a package that nobody > cares about who actually uses the architectures in question. > > Since over the years the Random Keyword Requests happen a *lot* right > after recruitment, it might even be useful to ask about this in the > quizzes. (The answer: your time is better spent fixing actual bugs. > bumping versions, adding features and maintaining a stable branch, > rather than raising the architecture count for your packages for no > adequately explored reason.) > > > Kind regards, > jer > To make sure I understand what you're getting at, are you saying some devs get on board and then request to add keywords to packages that they already maintain? If said arches are already supported in Gentoo I see little problem with that, especially if they intend on being part of the arch testing team for that arch or have access to the hardware. But if this is a case of developers asking for arch keywords to be added for arches that aren't (yet) supported in Gentoo, I agree that we need some sort of formal requirements, much like we do for stabilization (30 days no bugs, etc). Covering it in the devmanual is a great idea. How many packages do you think is necessary before 'critical mass' is reached and Gentoo should support it? I'm thinking it's less about the number of packages, and more about the community around that arch as well as whether or not a stage3 can be built for that arch in a reasonable timeframe. If it can get coreutils up and going, a stage3 can be built, and the handbook can be followed for that arch without issues (say, with an overlay), it seems like that would be a case for adding the keyword. But adding keywords, as we know, comes with maintenance burden. New arches can't get supported without people active in the community and actually using the hardware. If that interest isn't there, why should we add the keywords to the main repo? Overlays may be a fine alternative. Just my 2¢. Thanks for bringing this up, it's a topic I didn't know was a concern. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Mart Raudsepp: > Ühel kenal päeval, K, 18.05.2016 kell 22:25, kirjutas > aide...@gentoo.org: >> From: Amadeusz Żołnowski >> >> awk doesn't have the -i option like sed and if editing file in >> place is desired, additional steps are required. eawk uses tmp >> file to make it look to the caller editing happens in place. --- >> eclass/eutils.eclass | 13 + 1 file changed, 13 >> insertions(+) >> >> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass index >> dbedffe..e331f1b 100644 --- a/eclass/eutils.eclass +++ >> b/eclass/eutils.eclass @@ -20,6 +20,19 @@ _EUTILS_ECLASS=1 >> >> inherit multilib toolchain-funcs >> >> +# @FUNCTION: eawk +# @USAGE: +# @DESCRIPTION: +# >> Edit file in place with awk. Pass all arguments following >> to +# awk. >> > > I would like if such a function would explicitly document that > calling this function means the caller should DEPEND on an awk > provider. Similarly, I would like that all ebuild that call 'sed' > actually DEPEND on sed, not just half of them. According to PMS, sed is guaranteed to be present[0]. > I would also like that no ebuild would assume packages in @system > to be present, beyond those dictated by PMS (unpackers and such). > Quoting PMS [1]: "[...] in most cases this means that the only packages that can be assumed to be present are those listed in the base profile or equivalent [...]" Implicit system dependencies are documented in devmanual as well. May I ask why you are against it? > Mart > [0] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12700011.3.1.1 [1] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12600011.3.1 -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXPkxQAAoJEIT4AuXAiM4zH/gH/2KJIdAbL1x8TfvWIeOnjQ4E IatAXY9DentQgGVFHU+bwOj+bdgMfaU3QACjDAD/GOPYTwrOSlHD2dK7spkou7RS VY3voejyvK1tHASooMvEaaH8VQ9HMe82JDS64YTfxMLFb8FcwJOYde3plVSFPArA UGhNCzEpgMJBkd89lS/BsmtHqS0czuAO+VJdVttMo1EyW8CR1s6ou+FVzymgJM/+ P8Zg6eVIcyJOQqQcnpRbDPvSw2lGNP7BofZjFng578DNz3F1LAtdBFBujNNT3kUW FgbifW7Y53hnx3nYjjBigBp8ERm3HuhDXQiQMNEOsFlfIWKarp4017NC8BmH9i4= =jHCS -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Ühel kenal päeval, K, 18.05.2016 kell 22:25, kirjutas aide...@gentoo.org: > From: Amadeusz Żołnowski > > awk doesn't have the -i option like sed and if editing file in place > is > desired, additional steps are required. eawk uses tmp file to make it > look to the caller editing happens in place. > --- > eclass/eutils.eclass | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass > index dbedffe..e331f1b 100644 > --- a/eclass/eutils.eclass > +++ b/eclass/eutils.eclass > @@ -20,6 +20,19 @@ _EUTILS_ECLASS=1 > > inherit multilib toolchain-funcs > > +# @FUNCTION: eawk > +# @USAGE: > +# @DESCRIPTION: > +# Edit file in place with awk. Pass all arguments following > to > +# awk. > I would like if such a function would explicitly document that calling this function means the caller should DEPEND on an awk provider. Similarly, I would like that all ebuild that call 'sed' actually DEPEND on sed, not just half of them. I would also like that no ebuild would assume packages in @system to be present, beyond those dictated by PMS (unpackers and such). Mart
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
On Thu, May 19, 2016 at 10:50:48PM +0100, Amadeusz Żołnowski wrote:
> "Robin H. Johnson" writes:
> > 1.
> > If your AWK command has an error, then this clobbers the file, a
> > better variant, with die, would be:
> > awk "$@" "$f" >"${tmpf}" || die "awk failed..."
> > cp -f "${tmpf}" "$f" || die "copy back failed"
>
> Thanks! On the one hand it's a simple function, and on the other hand
> there are several things which can go wrong. I will submit corrected
> version with unit test.
>
> Why '-f' is required?
Corner cases w/ copying and bad ebuild usage (specifically running
ebuild as two different non-root users during development). Mostly
habit.
Another thought I had, is that if you're using eawk on something in
$ROOT, you're also going to clobber ownership, permissions and extended
attributes.
> >> # @USAGE:
> > This calling format is also a problem if they intended to pass multiple
> > files to the command, or if they do so accidentally.
> >
> > Eg, an unprotected glob in the first argument, eg:
> > eawk foo* '/foobar/{$1="x"; print $0}'
> >
> > If foo1 and foo2 existed, this would be considered as:
> > awk foo2 /foobar/{$1="x"; print $0}' foo1
> >
> > which really will NOT have the desired effect.
>
> I am aware of this. I considered before:
>
> a) eawk files... -- awk_args...
> b) eawk awk_args -- pattern files...
>
> making '--' required, but that just complicates usage and function
> itself. And anyway isn't it true for any other command with careless
> glob use?
>
> I have documented that function takes a file, not files. The effect of
> misuse eawk would be awk error. Although maybe it would be useful to
> support multiple files? Then I'd go for variant (b) probably.
If we declare the calling format in BSD style:
Then this is negated, but means you need to be able to find the first
file in the list, which requires parsing the options correctly.
Another variation that you haven't considered above is passing multiple
programs to awk via -e or -f options, in which case there is no
non-option program argument.
I agree generally that this is a useful idea, but there's a lot of
caveats and corner-cases :-(.
--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
"Robin H. Johnson" writes:
> 1.
> If your AWK command has an error, then this clobbers the file, a
> better variant, with die, would be:
> awk "$@" "$f" >"${tmpf}" || die "awk failed..."
> cp -f "${tmpf}" "$f" || die "copy back failed"
Thanks! On the one hand it's a simple function, and on the other hand
there are several things which can go wrong. I will submit corrected
version with unit test.
Why '-f' is required?
>> # @USAGE:
> This calling format is also a problem if they intended to pass multiple
> files to the command, or if they do so accidentally.
>
> Eg, an unprotected glob in the first argument, eg:
> eawk foo* '/foobar/{$1="x"; print $0}'
>
> If foo1 and foo2 existed, this would be considered as:
> awk foo2 /foobar/{$1="x"; print $0}' foo1
>
> which really will NOT have the desired effect.
I am aware of this. I considered before:
a) eawk files... -- awk_args...
b) eawk awk_args -- pattern files...
making '--' required, but that just complicates usage and function
itself. And anyway isn't it true for any other command with careless
glob use?
I have documented that function takes a file, not files. The effect of
misuse eawk would be awk error. Although maybe it would be useful to
support multiple files? Then I'd go for variant (b) probably.
Cheers,
--
Amadeusz Żołnowski
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Ulrich Mueller writes:
> Yes, of course. "|| die -n || return" if you want the function to
> return at that point, if it was called under nonfatal.
>
>> https://blogs.gentoo.org/mgorny/2015/11/13/the-ultimate-guide-to-eapi-6
>
> Note that the ${?} in the code example there is redundant.
Why redundant? I imagine we can call it like:
if ! nonfatal efoo; then
do_something_on_error
fi
can't we?
-- Amadeusz Żołnowski
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
> On Thu, 19 May 2016, Mart Raudsepp wrote:
>> Ulrich Mueller writes:
>> > The EAPI 6 method would be to use "|| die -n". Then the caller
>> > either call "eawk" if the function should die automatically, or
>> > "nonfatal eawk" if it should return with an error status.
> Don't you possibly need a || return as well in there if it isn't the
> last things in the function?
Yes, of course. "|| die -n || return" if you want the function to
return at that point, if it was called under nonfatal.
> https://blogs.gentoo.org/mgorny/2015/11/13/the-ultimate-guide-to-eapi-6
Note that the ${?} in the code example there is redundant.
Ulrich
pgpzKKMVTEdhY.pgp
Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Ühel kenal päeval, N, 19.05.2016 kell 18:51, kirjutas Amadeusz Żołnowski: > Ulrich Mueller writes: > > The EAPI 6 method would be to use "|| die -n". Then the caller can > > either call "eawk" if the function should die automatically, or > > "nonfatal eawk" if it should return with an error status. Don't you possibly need a || return as well in there if it isn't the last things in the function? https://blogs.gentoo.org/mgorny/2015/11/13/the-ultimate-guide-to-eapi-6 > Yes, that seems better. Hasn't it been introduced earlier than in > EAPI 6? die -n argument is new in EAPI 6 nonfatal was added in EAPI 4, together with the fatality defaults for PM utilities. See https://devmanual.gentoo.org/ebuild-writing/eapi/ Mart
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Ulrich Mueller writes: > The EAPI 6 method would be to use "|| die -n". Then the caller can > either call "eawk" if the function should die automatically, or > "nonfatal eawk" if it should return with an error status. Yes, that seems better. Hasn't it been introduced earlier than in EAPI 6? -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] new developers' keyword requests
On Thu, May 19, 2016 at 10:51 AM, Jeroen Roovers wrote: > Perhaps it's a good idea to add a section to the devmanual about adding > new keywords to packages. > > Recruits in particular might benefit from some background on what > keywording means and when it should be done, especially before they > start maintaining packages and then realise their packages are so > beautiful that they positively *deserve* to have some random keywords > added. This is not productive. > > The way it works is that users of > specific architectures find that a package works for them on their > systems (which have enough resources and have the correct interfaces for > that particular program to be used conveniently, and so on), and that > they then request that their architecture keyword be added. What > doesn't work is having a handful of keywords on a package that nobody > cares about who actually uses the architectures in question. > > Since over the years the Random Keyword Requests happen a *lot* right > after recruitment, it might even be useful to ask about this in the > quizzes. (The answer: your time is better spent fixing actual bugs. > bumping versions, adding features and maintaining a stable branch, > rather than raising the architecture count for your packages for no > adequately explored reason.) > > > Kind regards, > jer > Both ideas (devmanual update + quiz question) seem good to me.
[gentoo-dev] new developers' keyword requests
Perhaps it's a good idea to add a section to the devmanual about adding new keywords to packages. Recruits in particular might benefit from some background on what keywording means and when it should be done, especially before they start maintaining packages and then realise their packages are so beautiful that they positively *deserve* to have some random keywords added. This is not productive. The way it works is that users of specific architectures find that a package works for them on their systems (which have enough resources and have the correct interfaces for that particular program to be used conveniently, and so on), and that they then request that their architecture keyword be added. What doesn't work is having a handful of keywords on a package that nobody cares about who actually uses the architectures in question. Since over the years the Random Keyword Requests happen a *lot* right after recruitment, it might even be useful to ask about this in the quizzes. (The answer: your time is better spent fixing actual bugs. bumping versions, adding features and maintaining a stable branch, rather than raising the architecture count for your packages for no adequately explored reason.) Kind regards, jer
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
> On Wed, 18 May 2016, Amadeusz Żołnowski wrote: >> Also, wouldn't the absence of 'die' cause silent breakages? > I want to caller decide whether die or not and what error messge to > give. The EAPI 6 method would be to use "|| die -n". Then the caller can either call "eawk" if the function should die automatically, or "nonfatal eawk" if it should return with an error status. Ulrich pgpdUEGb8D4lN.pgp Description: PGP signature
Re: [gentoo-dev] Continuous Stabilization (Regarding Post Install Test Scripts)
Dear Pallav,
how about using a dedicated eclass for arch-testing?
E.g., you might provide a function in some eclass
that only runs when called from pkg_postinst [1]
phase AND when some configuration option is set.
Then a maintainer / arch tester might provide
the tests inside the ebuild directory, e.g.,
inside a hidden sub-directory .arch-tests or
something like that, include your eclass inside
the ebuild and call your test-function from pkg_postinst
or something like that...
[1]
https://devmanual.gentoo.org/ebuild-writing/functions/pkg_postinst/index.html
Best wishes,
Harald.
Harald Weiner
Institute of Applied Geometry
Johannes-Kepler-Universität
Altenberger Straße 69
A-4040 Linz
harald.wei...@jku.at
http://www.ag.jku.at
On 05/19/2016 09:45 AM, Pallav Agarwal wrote:
> This is a continuation of "[gentoo-dev] Proposal for changes for the
> next EAPI
> version" thread. Since the former subject isn't very relevant anymore.
>
> Target:
> A place to provide scripts that can be used by an automated
> arch-tester bot to
> stabilize Gentoo packages. These scripts can be as simple as a one liner
>
> `python -c "import module"`
>
> for example in case of a python module. Or a little complex, for
> example to test
> different features in case of different USE flags.
> The main target is to alleviate the problems and unreliability from
> ARCH Testing
> and to more thoroughly and automatically test packages.
>
> 1 - Some important factors to consider from the previous thread:
> a) This must be run POST-MERGE so that problems after merging can be
> detected
> b) It should be hopefully scalable in both directions - similar tests
> for multiple packages
> - different tests for different versions of same package.
> c) If a users want, they should be able to run these tests too (If
> they do, bug reports
> collected will be very valuable.
> d) Most common opinion was to not have an EAPI change unless this
> gains enough
> use or demand.
> e) If implemented as a part of ebuild, it can have all benefits of an
> ebuild syntax.
> Different versions of a package can have different test scripts. Test
> code part can
> have its own conditional runtime dependencies (only to take effect IF
> testing is on).
> Also, it can have specific parts of test run or not dependent on USE
> flags enabled.
>
> 2 - Some suggested solutions
> a) The original proposed solution:
> To have an extra phase ci_test() or something similar that would be
> run ONLY when
> emerge is called with ci-test option. That way rest of the ebuild
> doesn't have to change,
> and for normal users, this wouldn't run unless they explicitly want it to.
>
> PROS:
> i) Full use of ebuild syntax
> ii) Users can also use.
> CONS:
> i) Requires EAPI change
> ii) Burdens the ebuild with more stuff
> iii) Existing ebuilds need to be changed (one more revision per ebuild)
>
> b) Having an extra global USE flag "ci_test" and putting test code in
> pkg_postinst
> phase under `if use ci_test` condition.
>
> PROS:
> i) Full use of ebuild syntax
> ii) Users can enable ci-test too
> iii) Changes to current ebuild standard is negligible
> CONS:
> i) Burdens the ebuild with more stuff
> ii) Existing ebuilds need to be changed (one more revision per ebuild)
>
> c) Creating a Gentoo Overlay with ebuilds which do test packages. And
> the testing
> script would be part of the pkg_postinst existing function.
> For example, overlay could have a package dev-python/numpy-ci-test with:
> ```
> DEPEND="dev-python/numpy"
> pkg_postinstall() {
> python -c "import numpy; numpy.test()" || die "failed"
> }
> ```
> as it's content.
>
> PROS:
> i) No change to existing ebuilds or EAPI
> ii) Can almost use all benefits of ebuild syntax
> iii) Anybody can submit tests for ebuilds to the corresponding ebuild
> on overlay
> iv) Eclasses can define CI tests for multiple packages at once
> CONS:
> i) Users will almost never use an overlay just for testing
> ii) Maintainer will have to submit one script for the portage tree and
> one for the overlay.
> Many maintainers would prefer to skip that.
> iii) Ebuild names need to be different from the ones in portage tree,
> so the process isn't
> transparent anymore. We first need to check if -ci-test package exists
> or not.
>
>
> Any more suggestions/comments/methods are invited.
>
> ---
> Regards,
> Pallav
[gentoo-dev] Continuous Stabilization (Regarding Post Install Test Scripts)
This is a continuation of "[gentoo-dev] Proposal for changes for the next
EAPI
version" thread. Since the former subject isn't very relevant anymore.
Target:
A place to provide scripts that can be used by an automated arch-tester bot
to
stabilize Gentoo packages. These scripts can be as simple as a one liner
`python -c "import module"`
for example in case of a python module. Or a little complex, for example to
test
different features in case of different USE flags.
The main target is to alleviate the problems and unreliability from ARCH
Testing
and to more thoroughly and automatically test packages.
1 - Some important factors to consider from the previous thread:
a) This must be run POST-MERGE so that problems after merging can be
detected
b) It should be hopefully scalable in both directions - similar tests for
multiple packages
- different tests for different versions of same package.
c) If a users want, they should be able to run these tests too (If they do,
bug reports
collected will be very valuable.
d) Most common opinion was to not have an EAPI change unless this gains
enough
use or demand.
e) If implemented as a part of ebuild, it can have all benefits of an
ebuild syntax.
Different versions of a package can have different test scripts. Test code
part can
have its own conditional runtime dependencies (only to take effect IF
testing is on).
Also, it can have specific parts of test run or not dependent on USE flags
enabled.
2 - Some suggested solutions
a) The original proposed solution:
To have an extra phase ci_test() or something similar that would be run
ONLY when
emerge is called with ci-test option. That way rest of the ebuild doesn't
have to change,
and for normal users, this wouldn't run unless they explicitly want it to.
PROS:
i) Full use of ebuild syntax
ii) Users can also use.
CONS:
i) Requires EAPI change
ii) Burdens the ebuild with more stuff
iii) Existing ebuilds need to be changed (one more revision per ebuild)
b) Having an extra global USE flag "ci_test" and putting test code in
pkg_postinst
phase under `if use ci_test` condition.
PROS:
i) Full use of ebuild syntax
ii) Users can enable ci-test too
iii) Changes to current ebuild standard is negligible
CONS:
i) Burdens the ebuild with more stuff
ii) Existing ebuilds need to be changed (one more revision per ebuild)
c) Creating a Gentoo Overlay with ebuilds which do test packages. And the
testing
script would be part of the pkg_postinst existing function.
For example, overlay could have a package dev-python/numpy-ci-test with:
```
DEPEND="dev-python/numpy"
pkg_postinstall() {
python -c "import numpy; numpy.test()" || die "failed"
}
```
as it's content.
PROS:
i) No change to existing ebuilds or EAPI
ii) Can almost use all benefits of ebuild syntax
iii) Anybody can submit tests for ebuilds to the corresponding ebuild on
overlay
iv) Eclasses can define CI tests for multiple packages at once
CONS:
i) Users will almost never use an overlay just for testing
ii) Maintainer will have to submit one script for the portage tree and one
for the overlay.
Many maintainers would prefer to skip that.
iii) Ebuild names need to be different from the ones in portage tree, so
the process isn't
transparent anymore. We first need to check if -ci-test package exists or
not.
Any more suggestions/comments/methods are invited.
---
Regards,
Pallav
