[gentoo-dev] Ebuild bumping policy wrt KEYWORDS

Posted: 08-25-2004, 02:20 AM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is there a written policy anyway for the behavior of carrying KEYWORDS
over from one version of an ebuild for a given package to another?

I've noticed in my wanderings though the portage tree forest that often
times keywords have a habit of disappearing without notice between
versions , and having a policy or guideline *shudder* to help establish
guidelines for this behavior (if one doesn't already exist).

Thanks,
- --
Jason Wever
Gentoo/Sparc Co-Team Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBK+cudKvgdVioq28RAiBiAJ0evW9k7cLPZdtNOxT2SY OxrU3iiQCeKF25
yJNGu59eHXqRIvpN4AFR6Uk=
=ihAN
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list
Reply With Quote

Responses to "[gentoo-dev] Ebuild bumping policy wrt KEYWORDS"

Jason Wever
Guest
Posts: n/a
 
Re: [gentoo-dev] Ebuild bumping policy wrt KEYWORDS
Posted: 08-25-2004, 04:10 AM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 24 Aug 2004, Jason Wever wrote:
> Is there a written policy anyway for the behavior of carrying KEYWORDS
> over from one version of an ebuild for a given package to another?
Ciaranm set me straight on this, so no replies necessary :)

Man does my head hurt though,
- --
Jason Wever
Gentoo/Sparc Co-Team Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBLADkdKvgdVioq28RAlkfAJ4rqTHsk59LjT+Z65qGqn IW1MTVegCcCF/T
hG1R4j2Qcd9sVndrXc7hNw0=
=X+Cl
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list
Reply With Quote
Chris Gianelloni
Guest
Posts: n/a
 
Re: [gentoo-dev] Ebuild bumping policy wrt KEYWORDS
Posted: 08-25-2004, 02:50 PM
On Tue, 2004-08-24 at 21:11, Jason Wever wrote:
> Is there a written policy anyway for the behavior of carrying KEYWORDS
> over from one version of an ebuild for a given package to another?
I wouldn't be able to point you to it, but I can swear I read somewhere
on g.o that it was acceptable to KEYWORD a new version of a package as
~arch if the previous version of that package was arch or ~arch.
> I've noticed in my wanderings though the portage tree forest that often
> times keywords have a habit of disappearing without notice between
> versions , and having a policy or guideline *shudder* to help establish
> guidelines for this behavior (if one doesn't already exist).
At the same time, I've heard that we should never KEYWORD *anything*
which we cannot test for ourselves. This has been my general way of
doing things. When I commit a new version of a package, I only KEYWORD
it for the arches I can test for, then I send a test request to the
remaining arches.

Which is the preferred method?

While the first could possibly introduce packages that are broken for a
specific arch, the second also adds to the problem of alternative arches
being behind the base (x86, here) arch many times, and also lends to
packages disappearing as they get older ebuilds cleaned up.

--
Chris Gianelloni
Release Engineering - Operations/QA Manager
Games - Developer
Gentoo Linux

Is your power animal a penguin?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBBLJlFkT4lNIS36YERAqTyAKCZe1NAL2gK26DDO6gR1t KWk88GhwCffASs
TsrxEjNFNR7jovtE2UfKSHc=
=Rs7U
-----END PGP SIGNATURE-----

Reply With Quote
Michael Kohl
Guest
Posts: n/a
 
Re: [gentoo-dev] Ebuild bumping policy wrt KEYWORDS
Posted: 08-25-2004, 04:40 PM
On Tue, 24 Aug 2004 21:00:50 -0600 (MDT)
Jason Wever <weeve@gentoo.org> wrote:
> On Tue, 24 Aug 2004, Jason Wever wrote:
>
> > Is there a written policy anyway for the behavior of carrying
> > KEYWORDS over from one version of an ebuild for a given package to
> > another?
>
> Ciaranm set me straight on this, so no replies necessary :)
Care to summarize what he told you? This would make the answer more
known to the community, plus save several people the same headaches
you're going through right now... ;-)

Regards,

--
Michael Kohl <citizen428@gentoo.org>

GnuPG key: http://dev.gentoo.org/~citizen428/citizen428.asc
0x90CA09E3 - 4D21 916E DBCE 72B8 CDC5 BD87 DE2D 91A2 90CA 09E3

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBLLB93i2RopDKCeMRAhsUAJ9NPhJNoI+sJyef8Kmxzo 152DKgHACgjv1n
jn4m/3rVVhYtEpvdTf4hlXg=
=fy5H
-----END PGP SIGNATURE-----

Reply With Quote
Jason Wever
Guest
Posts: n/a
 
Re: [gentoo-dev] Ebuild bumping policy wrt KEYWORDS
Posted: 08-26-2004, 04:20 AM
On Wed, 25 Aug 2004 17:30:02 +0200
Michael Kohl <citizen428@gentoo.org> wrote:
> Care to summarize what he told you? This would make the answer more
> known to the community, plus save several people the same headaches
> you're going through right now... ;-)
Basically what I was looking for was found at
http://www.gentoo.org/proj/en/devrel...?part=2&chap=5

Enjoy!
--
Jason Wever
Gentoo/Sparc Team Co-Lead

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBLVZFdKvgdVioq28RAm/LAJ49ccmCOlJpW2GEBqWSON/4Z7ugygCgjS4Y
LPV65d/y2JGXkLxo0tvZCjw=
=4YUB
-----END PGP SIGNATURE-----

Reply With Quote
Jason Wever
Guest
Posts: n/a
 
Re: [gentoo-dev] Ebuild bumping policy wrt KEYWORDS
Posted: 08-26-2004, 04:30 AM
On Wed, 25 Aug 2004 09:51:02 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> At the same time, I've heard that we should never KEYWORD *anything*
> which we cannot test for ourselves. This has been my general way of
> doing things. When I commit a new version of a package, I only KEYWORD
> it for the arches I can test for, then I send a test request to the
> remaining arches.
>
> Which is the preferred method?
It's sort of both.

According to
http://www.gentoo.org/proj/en/devrel...ap=5#doc_chap2,
if an ebuild had an ~arch or arch keyword in the previous version, the
policy is to make it ~arch in the new version. If for some reason the
package maintainer is of the impression the new version would break a
given arch, they may omit the arch from the new version and request the
arch test out the package.

If the keyword didn't exist before and you can't test for it a given arch,
then yeah, don't keyword it lest we let jforman out of his cage again.

--
Jason Wever
Gentoo/Sparc Team Co-Lead

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBLVd9dKvgdVioq28RAkhbAJ0XOzPwf6+LXmHpBngegP WHz4horwCfQJhw
623hyWffjpuTPC8Aoip4Q8g=
=5G4a
-----END PGP SIGNATURE-----

Reply With Quote
Donnie Berkholz
Guest
Posts: n/a
 
Re: [gentoo-dev] Ebuild bumping policy wrt KEYWORDS
Posted: 08-26-2004, 06:00 AM
On Wed, 2004-08-25 at 22:22, Jason Wever wrote:
> According to
> http://www.gentoo.org/proj/en/devrel...ap=5#doc_chap2,
> if an ebuild had an ~arch or arch keyword in the previous version, the
> policy is to make it ~arch in the new version. If for some reason the
> package maintainer is of the impression the new version would break a
> given arch, they may omit the arch from the new version and request the
> arch test out the package.
I also would hesitate to auto-~arch fairly critical packages, such as X
or anything in system.
--
Donnie Berkholz
Gentoo Linux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBBLWvqXVaO67S1rtsRAjpEAKC9doTkE9MNiuuHW5rfKV Qwj2XBjQCfS2R3
6UjSR1NVV2gJNWyIIhPsjt8=
=dLpA
-----END PGP SIGNATURE-----

Reply With Quote
Jason Wever
Guest
Posts: n/a
 
Re: [gentoo-dev] Ebuild bumping policy wrt KEYWORDS
Posted: 08-26-2004, 06:30 AM
On Wed, 25 Aug 2004 23:49:47 -0500
Donnie Berkholz <spyderous@gentoo.org> wrote:
> I also would hesitate to auto-~arch fairly critical packages, such as X
> or anything in system.
For larger || more troublesome || tool-chain type packages, we've
historically worked with the package maintainers in keywording new
versions to help with this. In cases like this that is
acceptable/agreeable. This might be a fine print item for that portion of
the handbook.

Personally, I would rather run into a package breaking in a revbump than
have it be missing keywords and not notified that it was behind. While yes
this stinks from a QA perspective, it also gets the problem addressed and
resolved quicker (usually) than running into it later on down the road.
It's also a lot easier wrt the overhead the package maintainers, arch
maintainers and infrastructure maintainers have to go through to
accomidate extra emails, bugs, etc if test requests had to be issued each
time a package got rev or version bumped in the portage tree.

Granted that's just my preference, but I've got my flame retardant
underoos on so fire away ;)


--
Jason Wever
Gentoo/Sparc Team Co-Lead

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBLXMydKvgdVioq28RArg+AJsEUpt7duzT3bKcyW9eav a7ppiDPQCgmk1X
Ln0qsCmQT8jxCw3+W/1RuSA=
=3WuO
-----END PGP SIGNATURE-----

Reply With Quote
Donnie Berkholz
Guest
Posts: n/a
 
Re: [gentoo-dev] Ebuild bumping policy wrt KEYWORDS
Posted: 08-26-2004, 07:30 AM
On Thu, 2004-08-26 at 00:20, Jason Wever wrote:
> On Wed, 25 Aug 2004 23:49:47 -0500
> Donnie Berkholz <spyderous@gentoo.org> wrote:
>
> > I also would hesitate to auto-~arch fairly critical packages, such as X
> > or anything in system.
>
> For larger || more troublesome || tool-chain type packages, we've
> historically worked with the package maintainers in keywording new
> versions to help with this. In cases like this that is
> acceptable/agreeable. This might be a fine print item for that portion of
> the handbook.
>
> Personally, I would rather run into a package breaking in a revbump than
> have it be missing keywords and not notified that it was behind.
I'm sorry, I took it as a given that the archs would be notified in this
case. I guess I shouldn't have. =)
--
Donnie Berkholz
Gentoo Linux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBBLYDeXVaO67S1rtsRAodvAJ9ZD00001MBeXNObzLAJo hKZOnGOQCeLmp+
hyVvAjDbdClcORSffMyLrek=
=Up0P
-----END PGP SIGNATURE-----

Reply With Quote
Chris Gianelloni
Guest
Posts: n/a
 
Re: [gentoo-dev] Ebuild bumping policy wrt KEYWORDS
Posted: 08-26-2004, 03:20 PM
On Thu, 2004-08-26 at 01:20, Jason Wever wrote:
> Personally, I would rather run into a package breaking in a revbump than
> have it be missing keywords and not notified that it was behind. While yes
> this stinks from a QA perspective, it also gets the problem addressed and
> resolved quicker (usually) than running into it later on down the road.
> It's also a lot easier wrt the overhead the package maintainers, arch
> maintainers and infrastructure maintainers have to go through to
> accomidate extra emails, bugs, etc if test requests had to be issued each
> time a package got rev or version bumped in the portage tree.
So for Sparc, I should just KEYWORD away (on non-critical packages) and
hope nothing breaks?

(Though I will be testing on my U2 once I get my hard drive in for it.)

--
Chris Gianelloni
Release Engineering - Operations/QA Manager
Games - Developer
Gentoo Linux

Is your power animal a penguin?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBBLfCpkT4lNIS36YERApnyAKCEQP5AIN3pqYjenRNXiC EHx0WKGACcCIgM
tZ+eaMZPd538AsgPtciMEck=
=63by
-----END PGP SIGNATURE-----

Reply With Quote
 
LinkBack Thread Tools Display Modes
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[gentoo-dev] My first ebuild (trn) Chris L. Mason Gentoo Linux 7 08-06-2004 02:00 AM
[gentoo-dev] Creating an ebuild for XEmacs and GNU Emacs Jürgen Hötzel Gentoo Linux 2 07-10-2004 11:20 AM
[gentoo-dev] Captain's Logs for Tedious Ebuild Tasks Josh Glover Gentoo Linux 0 06-22-2004 01:00 PM
[gentoo-dev] From [gentoo-portage-dev] some problems about inn ebuild Sven Wegener Gentoo Linux 0 06-22-2004 05:50 AM
[gentoo-dev] Automatic ebuild stabilization Joel Konkle-Parker Gentoo Linux 1 06-19-2004 02:10 AM


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90