On Jun 12, 2007, at 2:14 PM, Carsten Lohrke wrote:
Could you please stop spamming the list with your one sentence
replies!
Waiting a day and then sending a single subsuming reply to the most
important
arguments suffices completely. The mailing list is not a chat channel.
Carsten
Hi list,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
cilly wrote:
> On Jun 12, 2007, at 12:55 PM, Marius Mauch wrote:
>> - a mistake in the ebuild prevents installation for 10% of the users,
>> but doesn't affect runtime behavior. SHould we bump it just for that
>> and "force" the other 90% of the users
On Jun 12, 2007, at 1:56 PM, Christoph Mende wrote:
It seems a bit that you didn't fully understand that case. That
package
fails to install for 10% but works flawlessly for the other 90%. Those
10% will get the fix even without a version bump, the other 90% don't,
but that's ok, they don't ne
On Jun 12, 2007, at 1:50 PM, Vlastimil Babka wrote:
I don't agree for hard-masked packages. Sometimes they are hard-masked
because of being under development, and are changed several times
until
unmasked (think about new KDE versions etc). Revbumping with each
change
and then finally unmask
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
cilly wrote:
> I also recommend to manage hard-masked packages the same way, it
> prevents confusion in
> bug-reports.
I don't agree for hard-masked packages. Sometimes they are hard-masked
because of being under development, and are changed several t
On Jun 12, 2007, at 12:55 PM, Marius Mauch wrote:
Hi Marius,
Not realistic. Think about it:
- upstream location for a package changes, so old SRC_URI stops
working. If we don't update the existing ebuild people can't use it
anymore, if we bump it to a new revision existing users "have to"
perfo
On Tue, 12 Jun 2007 12:07:11 +0200
cilly <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I think it is worth to discuss about `Do not modify ebuilds which
> are already in the tree... even if masked.`
>
> Sometimes ebuilds which are already in the portage tree are modified
> without changing the
> ve
On Jun 12, 2007, at 12:20 PM, Petteri Räty wrote:
http://devmanual.gentoo.org/general-concepts/ebuild-revisions/
index.html
This is the current policy. So far it has worked quite well for me
at least.
Okay, does this include ~ packages? And what about hard masked ones?--
[EMAIL PROTECTED]
On Jun 12, 2007, at 12:21 PM, Luca Barbato wrote:
There is already a guideline about it it basically says :
"Every changes that just fix an issue for a certain deals of users
(e.g.
optional dep version bump, different use handling, anything that
makes
the program not build just in that pa
cilly kirjoitti:
> Hi all,
>
> I think it is worth to discuss about `Do not modify ebuilds which are
> already in the tree... even if masked.`
>
> Sometimes ebuilds which are already in the portage tree are modified
> without changing the
> version-number, i.e. ebuild-r1 is in the portage tree an
cilly wrote:
> What do you think?
There is already a guideline about it it basically says :
"Every changes that just fix an issue for a certain deals of users (e.g.
optional dep version bump, different use handling, anything that makes
the program not build just in that particular case BUT doesn
On Tue, Jun 12, 2007 at 12:07:11PM +0200, cilly wrote:
> Hi all,
>
> I think it is worth to discuss about `Do not modify ebuilds which are
> already in the tree... even if masked.`
>
> Sometimes ebuilds which are already in the portage tree are modified
> without changing the version-number,
Hi all,
I think it is worth to discuss about `Do not modify ebuilds which are
already in the tree... even if masked.`
Sometimes ebuilds which are already in the portage tree are modified
without changing the
version-number, i.e. ebuild-r1 is in the portage tree and the ebuild-
r1 gets chan
13 matches
Mail list logo
