Re: [gentoo-dev] LICENSE and revbumps
> 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
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-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 categories introduces >>> needless complexity without bringing any really useful benefits. >> Could you elaborate on this categories complexity? I think that the idea is >> to >> just use already available categories, not implementing additional PROPERTY >> for this functionality. > > > Forcing a relationship with the category name seems more complex and > less flexible than simply having the ability to define > PROPERTIES=virtual in any given ebuild. Let me explain a bit more in case it's not clear. By forcing a relationship between the category and some other property, and removing the flexibility that would exist had this relationship not been forced, you end up having to add the additional complexity of package splits in order to achieve what could have otherwise been accomplished without any package splits. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAki01awACgkQ/ejvha5XGaMy6wCg3VMSZr4KyARF2RNyC5OSwxky yvEAn2lR8XOmBBqWC23sl4BZMST/VNcI =7oU2 -END PGP SIGNATURE-
Re: [gentoo-dev] LICENSE and revbumps
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 as if *you* incorrectly published the software anew - you just tagged on the wrong license initially, and by referring to the wrong license, you aren't somehow magically relicensing the software. As for the technical bit - when a user cannot install something because the license is masked by his package manager, and he discovers that the wrong license was attached, then he can do and should do two things: 1) notify the ebuild's maintainer(s) that the wrong license is being referred to. 2) unmask the license, confident that the reference in the ebuild is wrong, now that he's personally checked it. Kind regards, JeR
[gentoo-dev] Re: media-fonts/droid licensing: should fonts include Apache license in tarball?
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 are > there). Should we RESTRICT="mirror" in such case or it's safe to drop > such restriction? > > [1] > http://damieng.com/blog/2007/11/14/droid-sans-mono-great-coding-font > > Thank you for any hints, RESTRICT=mirror is probably the safest bet. Both Apache licenses require a copy to be included when redistributing, source or binary. PS. Badger him into switching to OFL while you're at it. ;) -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-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. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki0z0UACgkQcAWygvVEyALJcgCcDcrM/cFW60ewFLpoTFxIdVrr /AoAnAzBGukbmxOpfPai7bPI5BlCiJY1 =Lui3 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-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 >> needless complexity without bringing any really useful benefits. > > Could you elaborate on this categories complexity? I think that the idea is to > just use already available categories, not implementing additional PROPERTY > for this functionality. > Forcing a relationship with the category name seems more complex and less flexible than simply having the ability to define PROPERTIES=virtual in any given ebuild. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAki0xxMACgkQ/ejvha5XGaOI1QCgz9yfDUaAH+KnpbhrXtl5qPSn sccAn0KTXUPhw54KIBIk6soFHNNEkOHB =xQQ5 -END PGP SIGNATURE-
[gentoo-dev] Re: [RFC] What features should be included in EAPI 2?
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, however, src_prepare is marginally more > > useful than having a split src_configure. > > > How so? > > From a user point of view, and from a maintenance point of view, > src_configure is very useful. As a maintainer I would find it very useful to be able to do `ebuild foo-1.ebuild ` to get the build dir into following states: a) pristine source (unpack) b) patched, seded, eautoreconf'd, or everything-else-we're-doing-in-src_unpack-right-now'd (prepare) c) ./configured (configure) d) compiled (compile) the state between a) and b) is very useful as anyone who has gone back and forth commenting and uncommenting epatch/eautoreconf lines in src_unpack (ie. everyone) can attest. between c) and d) would be less useful for me but still quite welcome. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] LICENSE and revbumps
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 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
> philosophical question - what determines the licence(s) a currently
> installed package is covered by? My thought is that this would be the
> value in /var/db/pkg/${P}/LICENSE, being the LICENSE value at install
> time, and therefore a change in the tree requires reinstallation to
> change that value.
Correct.
> On the other hand, it also seems completely ridiculous from a
> practical POV to have to wait 30 days (and waste arch team resources)
> to fix an incorrect licence on a stable package.
I think it should be sensible to make the stabilization request a lot
earlier specifying the reason behind the creation of that newer
revision in the bug and the stabilization process should be pretty much
automatic, without wasting to much time from arch teams.
On the other hand, I think it would be wise to create an explicit
exception for this case in stabilization rules and to allow the uploader
of the corrected ebuild to keep the same KEYWORDS instead of
downgrading them to unstable.
Kindest regards,
Yuri.
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
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 elaborate on this categories complexity? I think that the idea is to just use already available categories, not implementing additional PROPERTY for this functionality. -- Michal Kurgan http://dev.gentoo.org/~moloh
[gentoo-dev] LICENSE and revbumps
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
philosophical question - what determines the licence(s) a currently
installed package is covered by? My thought is that this would be the
value in /var/db/pkg/${P}/LICENSE, being the LICENSE value at install
time, and therefore a change in the tree requires reinstallation to
change that value.
On the other hand, it also seems completely ridiculous from a practical
POV to have to wait 30 days (and waste arch team resources) to fix an
incorrect licence on a stable package.
Thoughts?
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-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 the need for that particular property >>> in the first place. >> This has been suggested elsewhere in the thread [1] but I think the the >> PROPERTIES approach will be more flexible and practical for the reasons >> that I've already stated. >> >> [1] >> http://archives.gentoo.org/gentoo-dev/ > msg_65636255c9d284e51898e826cae09ffd.xml > > Maybe it's just 'cause I'm not a dev, but I don't see the reasons you > state there as a problem. I specifically addressed the java-virtuals > category by suggesting that the trigger could be on "virtual" in the > category, not on the single category "virtual", so java-virtuals would be > included as would any other *virtual* category, and the java folks > wouldn't have to move it after all. > > Moves as for kde/kde-meta might be an issue, but I don't believe any more > so than any other package move, and since they're "virtual", possibly > less so. The splits, as for qt, might be more confusing, but it's a > one-time split either now or (for future packages) whenever they go > virtual, at which point there's a lot of work going into them anyway. > >>From my perspective, that's not significant additional cost, at least > compared to the cost associated with the PROPERTIES=virtual in the first > place. Given the advantages, including the clarity of having the virtual > property out where all can see it in the category name itself, I think > it's worth the relatively small additional cost. > > That said, it'd be nice, and to me, worth the cost, particularly as > compared to the cost of implementing a new property anyway, but since I'm > not the one implementing it (in either the PM or the packages), feel free > to override that opinion. > > There's also conceivably some times when a virtual/pkg_name might not be > a proper fit regardless of the property, making the category proposal > somewhat less flexible. I can't think of anywhere that such might be the > case, but that doesn't mean there aren't such cases. But I still believe > the benefit of having the property out there for all to see more valuable > than any potentially lost flexibility. > 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. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAki0spcACgkQ/ejvha5XGaOTygCg0phbwIFENXHBKyKryAMkgQwo RJwAoOdcjRUJAmnPK/RTBV5S0REVaYhx =QzgD -END PGP SIGNATURE-
[gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
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. > > This has been suggested elsewhere in the thread [1] but I think the the > PROPERTIES approach will be more flexible and practical for the reasons > that I've already stated. > > [1] > http://archives.gentoo.org/gentoo-dev/ msg_65636255c9d284e51898e826cae09ffd.xml Maybe it's just 'cause I'm not a dev, but I don't see the reasons you state there as a problem. I specifically addressed the java-virtuals category by suggesting that the trigger could be on "virtual" in the category, not on the single category "virtual", so java-virtuals would be included as would any other *virtual* category, and the java folks wouldn't have to move it after all. Moves as for kde/kde-meta might be an issue, but I don't believe any more so than any other package move, and since they're "virtual", possibly less so. The splits, as for qt, might be more confusing, but it's a one-time split either now or (for future packages) whenever they go virtual, at which point there's a lot of work going into them anyway. >From my perspective, that's not significant additional cost, at least compared to the cost associated with the PROPERTIES=virtual in the first place. Given the advantages, including the clarity of having the virtual property out where all can see it in the category name itself, I think it's worth the relatively small additional cost. That said, it'd be nice, and to me, worth the cost, particularly as compared to the cost of implementing a new property anyway, but since I'm not the one implementing it (in either the PM or the packages), feel free to override that opinion. There's also conceivably some times when a virtual/pkg_name might not be a proper fit regardless of the property, making the category proposal somewhat less flexible. I can't think of anywhere that such might be the case, but that doesn't mean there aren't such cases. But I still believe the benefit of having the property out there for all to see more valuable than any potentially lost flexibility. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
-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 guaranteed to be an integer and not a combined thingy as above ;) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki0kZMACgkQ4UOg/zhYFuDftQCfWHv+AvkqNJgZ/VwyIc1AV9WS kJcAoIMmvsPv48GO4ixM4KE25TQtBHkm =F3DM -END PGP SIGNATURE-
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
-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' ' > IIRC, the revision-id is just like the Git $Id$, it's a hex string, not > an incremented counter like the revision number in CVS. > True ... it usually looks like [EMAIL PROTECTED] Though, if one enforces certain policies using the "main branch" located on the server like disallowing pushing and only allowing merges, one can safely use the branch-revno (which is incremental). Only oddity are revnos of merged branches (e.g. "193.1.10") Another approach would be to use the unix-timestamp of the last change. Though it is not a unique identifier per se, it should be sufficient here. It should be queriable in all VCS. Though it might be, that it is not possible using standard CLI and requires a plugin in some way (but I bet, an easy one ;)) - - Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki0j3UACgkQ4UOg/zhYFuDZ+QCdGm7Sjew2+27KCUB06lWf8aLr XBsAoIbJSke4xHyPiucYEmkuNVd9GPJ3 =jTaO -END PGP SIGNATURE-
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
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 incremented counter like the revision number in CVS. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpbbzrUE2Qbx.pgp Description: PGP signature
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
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
> > > asking the VCS for what files have changed since your last check
> > > time).
> > 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 part of "debian revision" of the packages. So I
> > need this part to be chronologically ordered, as opposed to have
> > only the knowledge of whenever the file has changed or not.
> I'd call that critically dangerous in missing some changes.
> If I have a file in $FILESDIR, and change it, but it has the same
> name, there is no commit to the ebuild, and your .debs won't pick up
> changes at all. This is usually for cases with compile fixes that
> don't need revision bumps at all, but sometimes there are also
> changes to scripts.
Yes, I know that this will not protect me against changes in a file from
${FILESDIR} nor a change in a file in ${A}, but that was the best way I
could think of to make debian source packages (I create as well) as
reproducible as possible.
For the source packages I create a debian/rules[1] file that basically
calls ebuild foo.ebuild with the right options and to compile and then
install to a temporary directory and then call some debhelper scripts
to turn that directory into a proper .deb package. So from my
perspective the .ebuild file can be considered part of the debian/rules
files and because of that I really need to keep track of changes in it.
And for the rest of files, I bump ( :-D ) another revision counter with
each rebuild of the same debian source package version, so until I find
some better way to catch changes in any bit of the source (be it the
ebuild, files from ${A} or files from ${FILESDIR)/) I still don't have
conflicts.
> If you're making binary package .debs, I gather that you are grabbing
> the (pre|post)(inst|rm) and setup blocks for inclusion?
Yes, I certainly do.
> That is an interesting use case, and would that would present a
> problem with any VCS migration.
> - Under SVN, you'd only have the global revision, which might not
> uniquely identify the file.
> - Bzr doesn't support keyword expansion in any released version. There
> are/were plans for it in 1.7, but I haven't seen anything since the
> first prototype.
> - Hg supports it with an extension:
> http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension
> But has warnings about why it sucks
> http://www.selenic.com/mercurial/wiki/index.cgi/KeywordPlan
> See the 'keyword update intervals' item (mainly having to touch
> every file in the repo sometimes).
> - Git supports only the $Id$ keyword, and expands it to the SHA1 of
> the file, which ends up being a duplicate of the information we have
> in the Manifest.
I am aware about this problem, and unless this is explicitly taken into
consideration on migration, I guess I'll have to keep a local database
of "order" of ebuilds as part of the metadata associated with each
distribution my tool creates.
[1] debian/rules files is a make file that provides the right targets
for debian tools call it and generate deb binary packages. So it
is kind of the equivalent of .ebuild scripts for debian.
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
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!!
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
-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 part of "debian revision" of the packages. So I need this >> part to be chronologically ordered, as opposed to have only the >> knowledge of whenever the file has changed or not. > > That is an interesting use case, and would that would present a problem > with any VCS migration. I don't see this problem ... I guess it is possible in all VCS to get the information, which global revision touched a specific file last. For example in bzr (these examples are conceived by me - so probably there is an easier way): bzr log -l1 --line $FILE | cut -f1 -d: - --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' ' And hg,svn,git sure have similar abilities. - - Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki0hZQACgkQ4UOg/zhYFuBTrgCeJ/2gfygwUvWCB5QOibsYz0mN sGMAnRmqz/ChCg6zSAVrS4JljP1+DYRV =g5fE -END PGP SIGNATURE-
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
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 that creates deb (as in Debian package format) based > distributions from gentoo packages and that tool encodes the CVS > revision as part of "debian revision" of the packages. So I need this > part to be chronologically ordered, as opposed to have only the > knowledge of whenever the file has changed or not. I'd call that critically dangerous in missing some changes. If I have a file in $FILESDIR, and change it, but it has the same name, there is no commit to the ebuild, and your .debs won't pick up changes at all. This is usually for cases with compile fixes that don't need revision bumps at all, but sometimes there are also changes to scripts. If you're making binary package .debs, I gather that you are grabbing the (pre|post)(inst|rm) and setup blocks for inclusion? That is an interesting use case, and would that would present a problem with any VCS migration. - Under SVN, you'd only have the global revision, which might not uniquely identify the file. - Bzr doesn't support keyword expansion in any released version. There are/were plans for it in 1.7, but I haven't seen anything since the first prototype. - Hg supports it with an extension: http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension But has warnings about why it sucks http://www.selenic.com/mercurial/wiki/index.cgi/KeywordPlan See the 'keyword update intervals' item (mainly having to touch every file in the repo sometimes). - Git supports only the $Id$ keyword, and expands it to the SHA1 of the file, which ends up being a duplicate of the information we have in the Manifest. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp8kuyAJCBo9.pgp Description: PGP signature
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
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, not native English speaker :$ > > But when foo-1.0-r4 is updated in-place, I use CVS revisions > > (ej: 1.12 -> 1.13 in 2nd word in $ Header: ) > The $Header$ is filled out automatically by CVS, what are you using > the $Header$ string for? > > 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 that creates deb (as in Debian package format) based distributions from gentoo packages and that tool encodes the CVS revision as part of "debian revision" of the packages. So I need this part to be chronologically ordered, as opposed to have only the knowledge of whenever the file has changed or not.
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
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 $ Header: ) The $Header$ is filled out automatically by CVS, what are you using the $Header$ string for? 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). -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpPq30jIkMcZ.pgp Description: PGP signature
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
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 and actively use? > > I use the revision present in the header to identify changes in > > ebuild files that didn't needed a revision dump. > Err, what do you mean by revision dump? revision dump is when foo-1.0-r4 becomes foo-1.0-r5. But when foo-1.0-r4 is updated in-place, I use CVS revisions (ej: 1.12 -> 1.13 in 2nd word in $ Header: ) Yuri.
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
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 > ebuild files that didn't needed a revision dump. Err, what do you mean by revision dump? -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp0q7G3TIQhD.pgp Description: PGP signature
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
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 never been a reason to ask this from the user for me. If the ebuild in question has changed without changing name, it has always been obvious if it matters, and if the user has an old version if it does (as then what the bug is about is what was just recently fixed without revbump, typically build fixes). > Q: Are there any other use-cases you have and actively use? No. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
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 changes in ebuild files that didn't needed a revision dump. Kindest regards, Yuri.
[gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
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 case? Q: Are there any other use-cases you have and actively use? For evaluating existing uses of the primary case, I took a glance at Bugzilla. There are 624 bugs total that contain a $Header$ with an existing Gentoo path. At least 143 of those are for new packages or version bumps (they copied existing ebuilds). -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpmjeA4IEyQM.pgp Description: PGP signature
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-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 PROPERTIES approach will be more flexible and practical for the reasons that I've already stated. [1] http://archives.gentoo.org/gentoo-dev/msg_65636255c9d284e51898e826cae09ffd.xml - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAki0QPEACgkQ/ejvha5XGaPtJgCdFTpDzQfSo6zARHSje8b+h7I7 OAAAnjzo8SdYaeZ7Cmqnj+5xUSHlU7i+ =Gj7B -END PGP SIGNATURE-
[gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
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's a virtual package in that it doesn't >> install anything itself, even if it's a meta-package [...] > > So what does 'virtual' actually mean then, and how is it related to the > defined behaviour of this property? I'm unsure of whether that was intended to be a rhetorical question or not, so taking it literally... According to kdict/WordNet: 2: being such in essence or effect though not in actual fact Extending that to the technical/computing realm, again kdict, this time FOLDOC and Jargon file: (Via the technical term virtual memory, probably from the term "virtual image" in optics) 1. Common alternative to logical; often used to refer to the artificial objects (like addressable virtual memory larger than physical memory) created by a computer system to help the system control access to shared resources. 2. Simulated; performing the functions of something that isn't really there. An imaginative child's doll may be a virtual playmate. Opposite of real or physical. So a virtual package would have the essence and effects of a real one (dependencies and the like) but not be "real" in some way (here, zero- install-cost, or more correctly, only the install cost of the dependencies). More directly, a package that doesn't actually install anything itself, only having dependencies that ensure other packages are installed. In original Gentoo usage, virtual packages didn't have ebuilds at all, but referred to dependencies that several different packages could provide, with the the profile generally specifying a default. Now many of them have ebuilds, but the general idea of not installing anything directly themselves, only thru dependencies, remains. This is equally true of the original no-ebuild virtuals, those ebuilds in the virtual/ categories, and various meta-packages such as kde and kde-meta. Thus, they fit the broader defintion of "virtual" in a literal sense, regardless of where they are located in the category tree. However, I like the idea someone else proposed as well. Move all these packages into the virtual category. That could of course be expanded to include java-virtuals if desired, since virtual is still part of the category name. Either as a single category or as anything with "virtual" in the category, this would make things easier for both the package manager (making the property unnecessary) and the user, who would then know on sight (in the tab-completion and in --pretend/ask as well as various $PM messages) which packages were virtual. Putting all virtual packages in the virtual category/ies would certainly simplify the task of explaining to confused users why removing say kde- base/games wanted to remove virtual/kde (instead of kde-base/kde), but wouldn't directly remove kdebase (tho emerge --depclean would then want to do so, until the user did an emerge --no-replace kdebase, at least), to use an example I saw in a different context recently. 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. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
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 meaning of the old-style virtual, that of selecting > one of many providers. So the only problem with virtual is the > narrower old meaning. Whether that's a big enough problem to worry > about is of course debatable, but I don't personally believe it is, > and find it every bit as clear and actually much less confusing than > zero-install-cost. So what does 'virtual' actually mean then, and how is it related to the defined behaviour of this property? -- Ciaran McCreesh signature.asc Description: PGP signature
