> Should LICENSE changes require a revision bump?
No, since it would be a waste of users' resources.
For example, if a dev has missed a change from GPL-2 to GPL-3 (which I
guess is a common case), would you really have users reinstall the
package in this case? What would be the benefit?
Ulrich
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico wrote:
> Michal Kurgan wrote:
>> On Tue, 26 Aug 2008 18:49:12 -0700
>> Zac Medico <[EMAIL PROTECTED]> wrote:
>
>>> The PROPERTIES approach still seems a lot simpler and practical to
>>> me. It seems to me that the approach involving categor
On Tue, 26 Aug 2008 20:17:48 -0600
Ryan Hill <[EMAIL PROTECTED]> wrote:
> Should LICENSE changes require a revision bump?
No.
Any ebuild should be published with a correct reference to a license.
If you initially publish the ebuild with a bad reference, you simply
correct it later on. It's not a
On Tue, 19 Aug 2008 17:25:42 +0400
Peter Volkov <[EMAIL PROTECTED]> wrote:
> Hello.
>
> There are droid fonts package in the tree. Author states that they are
> apache licensed [1] (supposedly similar to google's android sdk) but
> license itself is not included in the package (only .ttf files ar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan and others wrote:
|
| Moves as for kde/kde-meta might be an issue,
You can leave kde meta packages out of this discussion as our plan is to
move to sets. We're going to have sets for 4.1* and plan to completely
drop meta packages for 4.2.
- -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michal Kurgan wrote:
> On Tue, 26 Aug 2008 18:49:12 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>
>> The PROPERTIES approach still seems a lot simpler and practical to
>> me. It seems to me that the approach involving categories introduces
>> needle
On Tue, 19 Aug 2008 21:27:03 +0100
Steve Long <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> >> b) Does it really matter?
> >
> > In the grand scheme of things, no. In the grand scheme of things,
> > you only *need* a single src_ function. From a maintainer
> > convenience perspective, ho
On Tue, 26 Aug 2008 20:17:48 -0600
Ryan Hill <[EMAIL PROTECTED]> wrote:
> Should LICENSE changes require a revision bump?
A licence changes what get's installed, ok the files are the same, but
the meaning of having the same files is different. So I say yes.
> It kinda seems to me the answer shou
On Tue, 26 Aug 2008 18:49:12 -0700
Zac Medico <[EMAIL PROTECTED]> wrote:
> The PROPERTIES approach still seems a lot simpler and practical to
> me. It seems to me that the approach involving categories introduces
> needless complexity without bringing any really useful benefits.
Could you elabora
I have an interesting (to me anyways) question.
Should LICENSE changes require a revision bump?
It kinda seems to me the answer should be yes. I don't know if any PM
currently implements LICENSE filtering so there may not be any
technical reason for it yet. And so I guess it comes down to a
phi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
> Zac Medico <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
> excerpted below, on Tue, 26 Aug 2008 10:44:22 -0700:
>
>> Duncan wrote:
>>> I therefore believe I like just moving them all to a *virtual*/
>>> category better, thus obviating
Zac Medico <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
excerpted below, on Tue, 26 Aug 2008 10:44:22 -0700:
> Duncan wrote:
>> I therefore believe I like just moving them all to a *virtual*/
>> category better, thus obviating the need for that particular property
>> in the first place.
>
> Thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
René 'Necoro' Neumann schrieb:
> Only oddity are
> revnos of merged branches (e.g. "193.1.10")
Gnah - forget this issue.. from the main branch' viewpoint, the last
change is always in the merge revision, and not in a revision being
merged. So it is gu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson schrieb:
> On Wed, Aug 27, 2008 at 12:37:09AM +0200, Ren?? 'Necoro' Neumann wrote:
>> - --or: to have the unique rev-id instead of the branch-local rev-number--
>> bzr log -l1 --show-ids $FILE | grep "revision-id" | cut -f2 -d' '
> IIR
On Wed, Aug 27, 2008 at 12:37:09AM +0200, Ren?? 'Necoro' Neumann wrote:
> - --or: to have the unique rev-id instead of the branch-local rev-number--
> bzr log -l1 --show-ids $FILE | grep "revision-id" | cut -f2 -d' '
IIRC, the revision-id is just like the Git $Id$, it's a hex string, not
an increme
On Tue, 26 Aug 2008 15:25:16 -0700
"Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote:
> > > Why do you need to identify the changes? Considering that the
> > > checksum changes as well, is detecting change not sufficient? (or
> > > aski
Robin H. Johnson wrote:
> On Tue, Aug 26, 2008 at 03:59:09PM -0500, Yuri Vasilevski wrote:
>>> Err, what do you mean by revision dump?
>> revision dump is when foo-1.0-r4 becomes foo-1.0-r5.
> That's revision 'B'ump, not 'D'ump.
>
bumb!!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson schrieb:
> On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote:
>> I am writing a tool that creates deb (as in Debian package format) based
>> distributions from gentoo packages and that tool encodes the CVS
>> revision as
On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote:
> > Why do you need to identify the changes? Considering that the checksum
> > changes as well, is detecting change not sufficient? (or asking the
> > VCS for what files have changed since your last check time).
> I am writing a tool
On Tue, 26 Aug 2008 14:45:25 -0700
"Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 26, 2008 at 03:59:09PM -0500, Yuri Vasilevski wrote:
> > > Err, what do you mean by revision dump?
> > revision dump is when foo-1.0-r4 becomes foo-1.0-r5.
> That's revision 'B'ump, not 'D'ump.
Sorry, n
On Tue, Aug 26, 2008 at 03:59:09PM -0500, Yuri Vasilevski wrote:
> > Err, what do you mean by revision dump?
> revision dump is when foo-1.0-r4 becomes foo-1.0-r5.
That's revision 'B'ump, not 'D'ump.
> But when foo-1.0-r4 is updated in-place, I use CVS revisions
> (ej: 1.12 -> 1.13 in 2nd word in
On Tue, 26 Aug 2008 13:54:21 -0700
"Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 26, 2008 at 03:41:07PM -0500, Yuri Vasilevski wrote:
> > > I'm doing some research on our usages of the $Header$ keyword in
> > > our main CVS repo.
> > >
> > > Q: Are there any other use-cases you have
On Tue, Aug 26, 2008 at 03:41:07PM -0500, Yuri Vasilevski wrote:
> > I'm doing some research on our usages of the $Header$ keyword in our
> > main CVS repo.
> >
> > Q: Are there any other use-cases you have and actively use?
> I use the revision present in the header to identify changes in
> ebuil
On T, 2008-08-26 at 13:40 -0700, Robin H. Johnson wrote:
> The primary use-case that has been publicly stated before was for
> users
> to be able to identify to developers what version of a given ebuild they
> were using.
>
> Q: How much have you utilized the primary use case?
Never. There has ne
Hi,
On Tue, 26 Aug 2008 13:40:36 -0700
"Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
> I'm doing some research on our usages of the $Header$ keyword in our
> main CVS repo.
>
> Q: Are there any other use-cases you have and actively use?
I use the revision present in the header to identify chang
Hi folks,
I'm doing some research on our usages of the $Header$ keyword in our
main CVS repo.
The primary use-case that has been publicly stated before was for users
to be able to identify to developers what version of a given ebuild they
were using.
Q: How much have you utilized the primary use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
> I therefore believe I like just moving them all to a *virtual*/ category
> better, thus obviating the need for that particular property in the first
> place.
This has been suggested elsewhere in the thread [1] but I think the
the PRO
Ciaran McCreesh <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on Tue, 26 Aug
2008 14:20:44 +0100:
> On Tue, 26 Aug 2008 06:39:38 + (UTC) Duncan <[EMAIL PROTECTED]>
> wrote:
>> But I think virtual works just fine for kde-base/kde, too, if one
>> simply reads it literally -- it
On Tue, 26 Aug 2008 06:39:38 + (UTC)
Duncan <[EMAIL PROTECTED]> wrote:
> But I think virtual works just fine for kde-base/kde, too, if one
> simply reads it literally -- it's a virtual package in that it
> doesn't install anything itself, even if it's a meta-package rather
> than having the mea
29 matches
Mail list logo
