[gentoo-dev] package.mask-ed ebuilds

[gentoo-dev] package.mask-ed ebuilds

[Nirbheek Chauhan]

Hello!

So, I can't find any documentation about this; nor can I find a
best-practices list. Can we add broken ebuilds in-tree as long as they
are package.masked? automagic deps, wrong deps, missing deps, file
collisions, etc etc? Even if it makes the ebuild completely unusable
by itself?

If yes:

So we can add completely broken and useless stuff to tree as long as
it's package.masked?

If no:

What's the minimum amount of "working-ness" that an ebuild must have
to be added to tree? Who decides this? The QA team?


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] package.mask-ed ebuilds

[Krzysztof Pawlik]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

On 04/09/10 08:10, Nirbheek Chauhan wrote:
> Hello!
> 
> So, I can't find any documentation about this; nor can I find a
> best-practices list. Can we add broken ebuilds in-tree as long as they
> are package.masked? automagic deps, wrong deps, missing deps, file
> collisions, etc etc? Even if it makes the ebuild completely unusable
> by itself?
> 
> If yes:
> 
> So we can add completely broken and useless stuff to tree as long as
> it's package.masked?
> 
> If no:
> 
> What's the minimum amount of "working-ness" that an ebuild must have
> to be added to tree? Who decides this? The QA team?

Use common sense: if it's work in progress then committing a broken ebuild which
is p.masked is IMHO acceptable (especially if you need to bump/add more ebuilds
to get this one working). At the same time if you don't plan on improving it and
just want to get it committed somewhere - use overlay.

-- 
Krzysztof Pawlik  <nelchael at gentoo.org>  key id: 0xF6A80E46
desktop-misc, java, apache, ppc, vim, kernel, python...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 554 bytes --]

[gentoo-dev] Re: package.mask-ed ebuilds

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

On Fri, 9 Apr 2010 12:40:50 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:

> Hello!
> 
> So, I can't find any documentation about this; nor can I find a
> best-practices list. Can we add broken ebuilds in-tree as long as they
> are package.masked? automagic deps, wrong deps, missing deps, file
> collisions, etc etc? Even if it makes the ebuild completely unusable
> by itself?
> 
> If yes:
> 
> So we can add completely broken and useless stuff to tree as long as
> it's package.masked?
> 
> If no:
> 
> What's the minimum amount of "working-ness" that an ebuild must have
> to be added to tree? Who decides this? The QA team?

package.mask is good for when you have a bunch of stuff that needs to be
uncaged at the same time or for something potentially hazardous that needs
testing.  i wouldn't add something that is in itself broken.  i don't know if
it's allowed or not but an overlay is just more convenient for work like that.


-- 
fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] package.mask-ed ebuilds

[Mark Loeser]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

Nirbheek Chauhan <nirbheek@gentoo.org> said:
> So, I can't find any documentation about this; nor can I find a
> best-practices list. Can we add broken ebuilds in-tree as long as they
> are package.masked? automagic deps, wrong deps, missing deps, file
> collisions, etc etc? Even if it makes the ebuild completely unusable
> by itself?

Just use some common sense.  If its completely broken, it obviously
doesn't belong in the tree.  If its something that somewhat works and is
actively being worked on, then its probably safe to add it and
package.mask it, with the intent that you are working towards getting it
to a state that it will be unmasked.

-- 
Mark Loeser
email         -   halcy0n AT gentoo DOT org
email         -   mark AT halcy0n DOT com
web           -   http://www.halcy0n.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] package.mask-ed ebuilds

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]

On Fri, 9 Apr 2010 12:40:50 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:

> So, I can't find any documentation about this; nor can I find a
> best-practices list. Can we add broken ebuilds in-tree as long as they
> are package.masked? automagic deps, wrong deps, missing deps, file
> collisions, etc etc? Even if it makes the ebuild completely unusable
> by itself?

In my opinion, an ebuild should be added to the tree as long as it will
be useful to users. If your ebuild is WIP but you want to give some
users an option to already use it or get some feedback, you could
consider adding it.

Moreover, I wouldn't take dependency-related issues as a reason to mask
the ebuild. As long as it's not going to hurt users' system or (if it's
an version bump) replace working version with non-working one, it
doesn't need the mask.

So, it all depends on how useful the ebuild is, and how dangerous it
can become. If it just misses some polishes, it's acceptable -- as long
as you're going to maintain it and fix all the known issues ASAP.

Please notice that this is no official statement but only my personal
opinion on the topic.

-- 
Best regards,
Michał Górny

<http://mgorny.alt.pl>
<xmpp:mgorny@jabber.ru>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] package.mask-ed ebuilds

[Ben de Groot]

On 9 April 2010 21:22, Michał Górny <gentoo@mgorny.alt.pl> wrote:
> In my opinion, an ebuild should be added to the tree as long as it will
> be useful to users. If your ebuild is WIP but you want to give some
> users an option to already use it or get some feedback, you could
> consider adding it.

That's what we have overlays for. Move it to the tree once it's ready.

-- 
Ben de Groot
Gentoo Qt project lead developer
Gentoo Wiki project lead