Re: [gentoo-dev] Re: A few questions to our nominees
> Using live templates is something more ^^; For now it looks to me like it is only more work. Could you please clarify what new functionality they provide? -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Re: A few questions to our nominees
Fernando J. Pereda wrote: On 14 Jun 2008, at 22:18, Luca Barbato wrote: mainline glibc usually requires you to fix it or the rest of the world... What? I experienced that the hard way -_- (btw they are single packages, emerge =python- works as should) So what was your proposal all about? Doing something more. How is using versions 'doing something more'? Using live templates is something more ^^; lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 22:18, Luca Barbato wrote: Fernando J. Pereda wrote: On 14 Jun 2008, at 20:02, Luca Barbato wrote: Fernando J. Pereda wrote: On 14 Jun 2008, at 19:36, Luca Barbato wrote: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the "bump", that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. do you really want to use live ebuild of THOSE? Why not? mainline glibc usually requires you to fix it or the rest of the world... What? (btw they are single packages, emerge =python- works as should) So what was your proposal all about? Doing something more. How is using versions 'doing something more'? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Fernando J. Pereda wrote: On 14 Jun 2008, at 20:02, Luca Barbato wrote: Fernando J. Pereda wrote: On 14 Jun 2008, at 19:36, Luca Barbato wrote: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the "bump", that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. do you really want to use live ebuild of THOSE? Why not? mainline glibc usually requires you to fix it or the rest of the world... (btw they are single packages, emerge =python- works as should) So what was your proposal all about? Doing something more. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Bernd Steinhauser wrote: Wow, impressive. Actually, you can't be serious... I am. GLEP 54 for quite some time now and it works very well. adds nothing to - and sets usage as is. I just don't see any benefit from your proposal, on the contrary there are issues. No. And that includes the ordering. No. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
> > emerge -C @kde-svn > > > > emerge @kde-svn > > > > that should suffice. > > I don't see that working for something like, say, python or glibc. No need, emerge @kde-svn will re-merge all packages in the set by default. So unmerging isn't needed and it just works. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Ryan Hill wrote: > (...I would change the suffix to -live, just because i > hate the term "SCM" :P) ++ on using "live" and not the "scm" acronym (no matter which idea is selected), especially since there are various different acronyms for config mgmt (scm, cm...), and scm's meaning is less obvious at first glance. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Luca Barbato schrieb: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the "bump", that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. Wow, impressive. Actually, you can't be serious... Of course I can track 4.1.1 with -scm, too, but that was absolutely not the point and is by far not what I wanted. The point was to track the 4.1 branch and not tags inside. If you want to track something you write a template for such thing, you just need to put a meaningful name, portage won't care if foo-0.live is really bar branch baz from repo dup. Advanced testers should be able to pick the live template and help testing and should be able to smoothly update, I'm all for it. See, the problem here is, that, I have been using -scm as proposed in GLEP 54 for quite some time now and it works very well. I just don't see any benefit from your proposal, on the contrary there are issues. And that includes the ordering. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 20:02, Luca Barbato wrote: Fernando J. Pereda wrote: On 14 Jun 2008, at 19:36, Luca Barbato wrote: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the "bump", that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. do you really want to use live ebuild of THOSE? Why not? (btw they are single packages, emerge =python- works as should) So what was your proposal all about? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Fernando J. Pereda wrote: On 14 Jun 2008, at 19:36, Luca Barbato wrote: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the "bump", that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. do you really want to use live ebuild of THOSE? (btw they are single packages, emerge =python- works as should) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 19:36, Luca Barbato wrote: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the "bump", that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: A few questions to our nominees
On Sat, 14 Jun 2008 12:32:22 + Patrick Lauer <[EMAIL PROTECTED]> wrote: > Portage 2.2 and others support sets, portage 2.2 even supports > dynamic sets like the "@preserved-rebuild". Shouldn't be that hard to > add a "live-ebuilds" dynamic set. > (Comments on the feasibility of my idea from portage people > appreciated) Should be simple if there is a definite way to determine if an ebuild is a 'live' eubild or not, wether that's by examining the name/category/version/metadata/external list/moon phase doesn't really matter (well, moon phase might complicate it a bit ;) Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Sat, 14 Jun 2008 10:38:18 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Marius Mauch wrote: > > Ignoring possible semantic issues for the moment, > > Please point them so I could fix them properly ^^ For example all the ordering issues pointed out by others in this thread. Also the whole 'template' approach is likely going to introduce a number of issues. And as your proposal is lacking a lot of details more problems will come up over time. > > Which in turn either means that the PM has to internally support > > the SCMs or support some new phase functions to extract the > > revision. > > After some discussions with dev-zero, I think we'll need a new phase, > possibly trigged by maint, before I was thinking about adding it to > sync. What exactly do you mean with 'maint'? > > Plus it has similar (unstated) transition issues as GLEP-54, just > > avoids a new comparison algorithm and the CPV vs. atom issue. > > Hmm, give me more informations about your concern. Simply how would you actually introduce this stuff without breaking existing setups? Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the "bump", that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. Of course I can track 4.1.1 with -scm, too, but that was absolutely not the point and is by far not what I wanted. The point was to track the 4.1 branch and not tags inside. If you want to track something you write a template for such thing, you just need to put a meaningful name, portage won't care if foo-0.live is really bar branch baz from repo dup. Advanced testers should be able to pick the live template and help testing and should be able to smoothly update, I'm all for it. I have got a feeling, that you didn't have to deal with live packages that much yet. (No offense.) Beside e17 and ffmpeg you mean? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Ryan Hill wrote:
On Sat, 14 Jun 2008 17:55:27 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
Ryan Hill wrote:
So every user will have a different _preN version which would vary
depending on how often they rebuild the package and that has
absolutely no correlation with the revision number of the upstream
codebase. I'm sorry, but that's unacceptable. :/
You'd like to have the cflags and ldflags embedded in the name for
the same reason?
There's no need to set up a strawman. I expect that everyone
installing a version of a package is building from the same sources.
Do you really not see a problem here?
Well the idea is to have the revision/reference behave like CFLAGS and
src_uri such variables, sorry if I just said that backwards.
Okay, taking a different approach, what does an auto-incrementing
suffix gain us? The ability to auto-merge a live ebuild at regular
intervals? That's something that can easily be achieved without
mucking about mangling CPVs, in any implementation we decide on. What
is it about your particular idea that makes it worth the numerous
disadvantages that we've pointed out?
I don't see disadvantages, all I wanted is a simple way to archive this:
# emaint -r ffmpeg
# emerge ffmpeg -p
[ebuild U ] media-video/ffmpeg-0.4.9_pre1235 [0.4.9_pre1234] [1]
[1] from ffmpeg-0.4.9.live
# emerge ffmpeg
fails, configure changed
# vim /usr/portage/media-video/ffmpeg-0.4.9.live.ebuild *1*
fix it
# emerge ffmpeg -L
builds as should test suite ok, further tests ok, everything builds
using it.
# egen ffmpeg 0.4.9_p${date} *2*
# scp /usr/portage/distfiles/ffmpeg-0.4.9_p${date}.tar.bz2
dev.gento.org:place
# cp usr/portage/media-video/ffmpeg/ffmpeg-0.4.9_p${date}.ebuild
/var/cvs/gentoo-x86/media-video/ffmpeg/
# cd /var/cvs/gentoo-x86/media-video/ffmpeg/
# cvs add ffmpeg-0.4.9_p${date}.ebuild
# echangelog "New revision" && repoman ci -m "New revision"
[1] or just ffmpeg-0.4.9.live if you like better.
[2] emaint -g instead of egen
I do not want end users using this stuff.
If a user reports a bug in package-1.1_pre6, how do you determine
what revision he has installed? How can you even tell it's an scm
ebuild?
You can. The generated ebuild must have a reference to the checkout.
This is the first time you've mentioned this.
really? btw s/generated/recorded in the vdb.
Where would you find such information?
from the vcs since on unpack or before I have to have the sources and
thus the revision.
How would you know that the ebuild the user is using is a generated ebuild,
and not just a standard ebuild that happens to end in _pre6?
Being the maintainer I should know what's in the tree. If somebody
happens to use an overlay that shadows the main tree how you'd be able
to tell the difference from foo-1.2.3 and foo-1.2.3?
How would that information get into the ebuild? Would
it have to come from the various VCS eclasses?
Right.
What about those that don't have a way of getting at the revision number (like
say
cvs.eclass)?
A timestamp should do, I cannot think anything better. You want to have
in the recorded ebuild everything useful to replay the process.
Would it have to be placed there by the package manager?
Yes.
If so, then we're back to having to implement support for every VCS
inside the PM.
Having support inside the template to have such information in a
variable you can save (as CFLAGS and friends) doesn't require this =)
If I want to report a bug I find to upstream, how to I know what
revision I have? Yes there are hacks like ESCM_LOGDIR, but they're
different for every SCM and you have to opt-in to use them. Most
people don't even know about them.
The generated ebuild contains pretty much everything you need to fill
a bugreport.
Could you please provide an example of a generated ebuild so we can see
what kinds of info it contains?
I phrased that badly.
we have some phases:
given we have a simple ebuild
Once we get a new template we can trigger a phase that makes the pm
consider the existence of an ebuild alike the current - ones: they
pick the tip of the branch chosen from the repository defined.
But with the version generated as already said.
If such ebuild get chosen for merge it behaves pretty much like the
current ones, but the PM stores additional informations in the vdb
(using current subversion.eclass as example it records the equivalent of
ESVN_REVISION). Such informations let you know how to reproduce the
build and let you generate a static snapshot automatically.
A dirty and simple way to implement this stuff right now (abusing
everything) is to:
have a script that scans the tree for .live templates and generates
ebuild out of them and places them in an overlay
have those ebuild rewrite themselves in the vdb adding the information
needed.
Making it less dirty requires adding a new phase and possibly some new
functions as ciaranm suggested.
--
Luca Barbato
Gentoo Council Member
[gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 18:34:21 +0200 Bernd Steinhauser <[EMAIL PROTECTED]> wrote: > Ryan Hill schrieb: > No, the idea behind ESCM_LOGDIR was different. > If you just want the revision of the current installed thing, you can > grep through the environment. > > ESCM_LOGDIR mainly aimed to provide a history of revisions you > installed. So that you can then tell upstream "Hey, I have this > revision installed and it doesn't work, but this revision worked.". > So it is definitely related, but not the same. Well, true. But it does give you the latest version you installed. ;) It was the only example I could think of (and one I use constantly). gcc is nice enough that i can do `gcc -v` and get gcc version 4.3.2-pre20080612 built 20080614 (Gentoo SVN ebuild) rev. 136782 () but not everything works like that. -- 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
[gentoo-dev] Webapp with plugins
Hallo list, I stumble across a nice problem: At the moment i am creating the ebuilds for the Mandriva Management Console (http://mds.mandriva.org). the web Interface is php based so the webapp eclass would be the best way but know the show stopper the webiterface supports plugins so how can i say that this webapp is a plugin for another webapp thx in av Mario (geos_one) p.s.: if i have directed the request to the wrong list plz direct me to the right one thx. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Extending -scm with upstream revision awareness
On Sat, 14 Jun 2008 18:30:59 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > > * When installing an scm package with suitable EAPI to VDB / > > exndbam, rewrite the scm version to [EMAIL PROTECTED] > > so -scm will have a @ metachar to point that what's following is the > hash/revision/reference to avoid clashes. > The info output would consider branches and tags as well? The ID is merely equality comparable. So far as I'm aware, all scm systems can give you at least one of: * A numeric revision of whatever you've checked out (subversion r1234 etc) * A string revision of whatever you've checked out (git sha1 IDs) * When the last change was made. You can always do something like find dir/ -type f -printf '[EMAIL PROTECTED]' | sort -n | tail -n1 if you're dealing with a sucky SCM that has no global revisions... I suspect CVS is in this boat, if anyone's still using it... For subversion and git, this has the added devious advantage of making the revision / ID easily visible. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 17:55:27 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ryan Hill wrote: > > So every user will have a different _preN version which would vary > > depending on how often they rebuild the package and that has > > absolutely no correlation with the revision number of the upstream > > codebase. I'm sorry, but that's unacceptable. :/ > > You'd like to have the cflags and ldflags embedded in the name for > the same reason? There's no need to set up a strawman. I expect that everyone installing a version of a package is building from the same sources. Do you really not see a problem here? Okay, taking a different approach, what does an auto-incrementing suffix gain us? The ability to auto-merge a live ebuild at regular intervals? That's something that can easily be achieved without mucking about mangling CPVs, in any implementation we decide on. What is it about your particular idea that makes it worth the numerous disadvantages that we've pointed out? > > If a user reports a bug in package-1.1_pre6, how do you determine > > what revision he has installed? How can you even tell it's an scm > > ebuild? > > You can. The generated ebuild must have a reference to the checkout. This is the first time you've mentioned this. Where would you find such information? How would you know that the ebuild the user is using is a generated ebuild, and not just a standard ebuild that happens to end in _pre6? How would that information get into the ebuild? Would it have to come from the various VCS eclasses? What about those that don't have a way of getting at the revision number (like say cvs.eclass)? Would it have to be placed there by the package manager? If so, then we're back to having to implement support for every VCS inside the PM. > > If I want to report a bug I find to upstream, how to I know what > > revision I have? Yes there are hacks like ESCM_LOGDIR, but they're > > different for every SCM and you have to opt-in to use them. Most > > people don't even know about them. > > The generated ebuild contains pretty much everything you need to fill > a bugreport. Could you please provide an example of a generated ebuild so we can see what kinds of info it contains? -- 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: A few questions to our nominees
Ryan Hill schrieb: On Sat, 14 Jun 2008 11:53:51 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: Ciaran McCreesh wrote: On Sat, 14 Jun 2008 10:19:32 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev. 136737, after the merge do I have gcc-4.4.0_pre136737 or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) installed? it would be gcc-4.4.0_pre1 but you'll have the revision inside the ebuild as var so you can get it easily. (e.g. the description shows it) And when would gcc-4.4.0_pre2 become available? It will be available once you trigger again the generation or if you put a normal ebuild with such name. So every user will have a different _preN version which would vary depending on how often they rebuild the package and that has absolutely no correlation with the revision number of the upstream codebase. I'm sorry, but that's unacceptable. :/ If a user reports a bug in package-1.1_pre6, how do you determine what revision he has installed? How can you even tell it's an scm ebuild? If I want to report a bug I find to upstream, how to I know what revision I have? Yes there are hacks like ESCM_LOGDIR, but they're different for every SCM and you have to opt-in to use them. Most people don't even know about them. No, the idea behind ESCM_LOGDIR was different. If you just want the revision of the current installed thing, you can grep through the environment. ESCM_LOGDIR mainly aimed to provide a history of revisions you installed. So that you can then tell upstream "Hey, I have this revision installed and it doesn't work, but this revision worked.". So it is definitely related, but not the same. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Extending -scm with upstream revision awareness
Ciaran McCreesh wrote: * add src_fetch_extra or whatever to avoid doing the fetches in src_unpack. good idea. * add pkg_scm_info. It outputs a string containing no spaces. .live would need something a bit different. * When installing an scm package with suitable EAPI to VDB / exndbam, rewrite the scm version to [EMAIL PROTECTED] so -scm will have a @ metachar to point that what's following is the hash/revision/reference to avoid clashes. The info output would consider branches and tags as well? * When updating an scm package, do src_fetch_extra then pkg_scm_info. At user option, if the pkg_scm_info value hasn't changed and it's a reinstall, skip reinstalling. * At user option, and not by default, do the fetch / info stage *before* showing the "this is what we'll install" list. Sounds quite interesting. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Luca Barbato schrieb: Bernd Steinhauser wrote: In the -scm approach this means: trunk = -scm 4.1 branch = -4.1-scm so you'll be oblivious of changes needed inside the ebuild and you won't know what you merged last time you issued an emerge =foo-scm (that by itself it is a problem, since it is ambiguous) Huh? What has to do with the ordering? And finding out what I installed last time is trivial and not the point. With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the "bump", that shouldn't have been one at all. trunk = .live nope it would resolve as foo_pre1 -> meaningless. 4.1 branch = 4.1.1.live (before 4.1.1 has been released) correct, you can keep tracking 4.1.1, have interim snapshot pushed in portage to ~ if you are confident about them. Of course I can track 4.1.1 with -scm, too, but that was absolutely not the point and is by far not what I wanted. The point was to track the 4.1 branch and not tags inside. I have got a feeling, that you didn't have to deal with live packages that much yet. (No offense.) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 18:23, Luca Barbato wrote: Fernando J. Pereda wrote: nope it would resolve as foo_pre1 -> meaningless. So your proposal is unable to handle that case, right? You are forced to put a version, that's all. Which doesn't always make sense so we are back to 9 versions. I don't consider this an improvement over the current situation. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Fernando J. Pereda wrote: nope it would resolve as foo_pre1 -> meaningless. So your proposal is unable to handle that case, right? You are forced to put a version, that's all. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 18:03, Luca Barbato wrote: trunk = .live nope it would resolve as foo_pre1 -> meaningless. So your proposal is unable to handle that case, right? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Extending -scm with upstream revision awareness
Since some people have been asking about this... Here's how I'd see upstream revision awareness being added to the -scm proposal. * add src_fetch_extra or whatever to avoid doing the fetches in src_unpack. * add pkg_scm_info. It outputs a string containing no spaces. * When installing an scm package with suitable EAPI to VDB / exndbam, rewrite the scm version to [EMAIL PROTECTED] * When doing a pretend install, consider reinstalling any scm package that was installed more than $user_option ago, and mark it as "might reinstall". * When updating an scm package, do src_fetch_extra then pkg_scm_info. At user option, if the pkg_scm_info value hasn't changed and it's a reinstall, skip reinstalling. * At user option, and not by default, do the fetch / info stage *before* showing the "this is what we'll install" list. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Bernd Steinhauser wrote: MPlayer has a psychological issue with 1.0 versioning, still 1.0.live correctly isn't higher than 1.0 No, it is not. For mplayer it is correct. I'm MPlayer upstream as well. I do know. In the -scm approach this means: trunk = -scm 4.1 branch = -4.1-scm so you'll be oblivious of changes needed inside the ebuild and you won't know what you merged last time you issued an emerge =foo-scm (that by itself it is a problem, since it is ambiguous) With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. trunk = .live nope it would resolve as foo_pre1 -> meaningless. 4.1 branch = 4.1.1.live (before 4.1.1 has been released) correct, you can keep tracking 4.1.1, have interim snapshot pushed in portage to ~ if you are confident about them. 4.1 branch = 4.1.2.live (before 4.1.2 has been released) 4.1 branch = 4.1.3.live (before 4.1.3 has been released) same reasoning. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Ryan Hill wrote: So every user will have a different _preN version which would vary depending on how often they rebuild the package and that has absolutely no correlation with the revision number of the upstream codebase. I'm sorry, but that's unacceptable. :/ You'd like to have the cflags and ldflags embedded in the name for the same reason? If a user reports a bug in package-1.1_pre6, how do you determine what revision he has installed? How can you even tell it's an scm ebuild? You can. The generated ebuild must have a reference to the checkout. If I want to report a bug I find to upstream, how to I know what revision I have? Yes there are hacks like ESCM_LOGDIR, but they're different for every SCM and you have to opt-in to use them. Most people don't even know about them. The generated ebuild contains pretty much everything you need to fill a bugreport. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: A few questions to our nominees
Ryan Hill <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 14 Jun 2008 09:04:26 -0600: >> > Having a method that >> > lets the user choose that the PM should check the scm tree and update >> > the package if there's a new revision would be even better. >> >> I think that can be easily done if there's an easy way to pull the >> installed revision and currently available. The last discussions about >> that stalled without reaching agreement. > > I could have sworn subversion.eclass already did this but now I can't > find the code. I might have seen it in an overlay or on the forums. Isn't it subversion itself that does this, based on local and remote repository revision numbers? -- 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 -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 12:32:22 + Patrick Lauer <[EMAIL PROTECTED]> wrote: > Ok, here's a silly idea - > > tag the ebuilds with metadata. We already have RESTRICT, why not add > a "LIVE" variable. The package manager can then treat all ebuilds > with that tag differently. Scripts can find them easily. Or we could create a scm suffix and not have to parse ebuilds to get that info. As an added bonus live ebuilds are instantly identifiable and can use proper versions numbers instead of . > Portage 2.2 and others support sets, portage 2.2 even supports > dynamic sets like the "@preserved-rebuild". Shouldn't be that hard to > add a "live-ebuilds" dynamic set. Just as easy with -scm. > (Comments on the feasibility of my idea from portage people > appreciated) > > > Currently, users with Portage have to run something like: > > ~ emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \ > > ~compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \ > > ~emerald emerald-themes libcompizconfig compizconfig-python \ > > ~ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \ > > ~compiz-fusion fusion-icon > > That is the situation where you really love the sets in portage 2.2 - > by default portage will re-merge every ebuild from a set when run as > "emerge @your-custom-set". Now the overlay maintainer just has to > provide the sets with the overlay and users are happy. His problem is updating the packages in a specific order. I don't remember sets preserving merge order, but then again I wasn't looking. > > Having a method that > > lets the user choose that the PM should check the scm tree and > > update the package if there's a new revision would be even better. > > I think that can be easily done if there's an easy way to pull the > installed revision and currently available. The last discussions > about that stalled without reaching agreement. I could have sworn subversion.eclass already did this but now I can't find the code. I might have seen it in an overlay or on the forums. -- 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: Re: A few questions to our nominees
Patrick Lauer schrieb: On Saturday 14 June 2008 14:11:12 Bernd Steinhauser wrote: That's what metadata is there for. And ebuilds don't mind carrying a bit more ... after all it's just one line of text. So, what you want to do is to read every ebuild, if you want to find all live ebuilds? Metadata cache. It's there for a reason. Besides, what will you do to determine if an installed ebuild is a live one? Go through the metadata cache for the non-installed stuff? Go through these ebuilds? Sounds like fun... -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: A few questions to our nominees
Patrick Lauer schrieb: On Saturday 14 June 2008 14:11:12 Bernd Steinhauser wrote: That's what metadata is there for. And ebuilds don't mind carrying a bit more ... after all it's just one line of text. So, what you want to do is to read every ebuild, if you want to find all live ebuilds? Metadata cache. It's there for a reason. Still a lot slower. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 08:45:08 -0600 Ryan Hill <[EMAIL PROTECTED]> wrote: > Just curious, were you happy with the previous GLEP54 draft or were > there still issues that had to be addressed? As far as I'm concerned > it's fine. (though I would change the suffix to -live, just because i > hate the term "SCM" :P) I'm happy with GLEP 54 as being the first, easy half of getting proper scm support. It correctly solves the ordering and identification issues. The second, really difficult part is making the package manager aware of upstream scm revisions. That can be done later by building upon GLEP 54. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 14:01:15 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sat, 14 Jun 2008 14:27:22 +0200 > Luca Barbato <[EMAIL PROTECTED]> wrote: > > Many of them applies as well to the alternative proposal, I wonder > > how you could say we, council, had to vote the other proposal given > > such (and other) issues were open. > > No they don't. The alternative proposal is deliberately simple enough > to avoid those issues, whilst leaving the possibility of a larger > solution that does have scm revision awareness open for the future. Just curious, were you happy with the previous GLEP54 draft or were there still issues that had to be addressed? As far as I'm concerned it's fine. (though I would change the suffix to -live, just because i hate the term "SCM" :P) -- 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: Re: A few questions to our nominees
On Saturday 14 June 2008 14:11:12 Bernd Steinhauser wrote: > > That's what metadata is there for. And ebuilds don't mind carrying a bit > > more ... after all it's just one line of text. > > So, what you want to do is to read every ebuild, if you want to find all > live ebuilds? Metadata cache. It's there for a reason. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 11:53:51 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Sat, 14 Jun 2008 10:19:32 +0200 > > Luca Barbato <[EMAIL PROTECTED]> wrote: > >>> I'm confused. If I have a gcc-4.4.0.live ebuild which checks out > >>> rev. 136737, after the merge do I have gcc-4.4.0_pre136737 > >>> or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) > >>> installed? > >> it would be gcc-4.4.0_pre1 but you'll have the revision inside the > >> ebuild as var so you can get it easily. (e.g. the description shows > >> it) > > > > And when would gcc-4.4.0_pre2 become available? > > It will be available once you trigger again the generation or if you > put a normal ebuild with such name. So every user will have a different _preN version which would vary depending on how often they rebuild the package and that has absolutely no correlation with the revision number of the upstream codebase. I'm sorry, but that's unacceptable. :/ If a user reports a bug in package-1.1_pre6, how do you determine what revision he has installed? How can you even tell it's an scm ebuild? If I want to report a bug I find to upstream, how to I know what revision I have? Yes there are hacks like ESCM_LOGDIR, but they're different for every SCM and you have to opt-in to use them. Most people don't even know about them. I think the request to create some kind of auto-updating system for live ebuilds is a red herring, and will make finding a reasonable solution much much harder than it should be. If people want to auto-update their live ebuilds they can simply put them in a cron job. -- 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: Re: A few questions to our nominees
Patrick Lauer schrieb: On Saturday 14 June 2008 11:53:51 Jorge Manuel B. S. Vicetto wrote: What's the need for a GLEP covering "live" ebuilds and what's wrong with - ebuilds? I made myself that question when GLEP54 was submitted and during the initial discussion. At that time, I wasn't convinced of the need for such a GLEP. Now I think it can be very useful. Why did I change my mind? Let's have a concrete use case. Updating the live ebuilds for compiz, can be a mess. If the ebuilds aren't updated in the correct order, the process will fail and leave users wondering why it failed. What we need is a way to ask the PM to update compiz-fusion and or fusion-icon and all its "live" deps. Ok, here's a silly idea - tag the ebuilds with metadata. We already have RESTRICT, why not add a "LIVE" variable. The package manager can then treat all ebuilds with that tag differently. Scripts can find them easily. It is forwards and backwards compatible and doesn't cause any user-visible changes. Portage 2.2 and others support sets, portage 2.2 even supports dynamic sets like the "@preserved-rebuild". Shouldn't be that hard to add a "live-ebuilds" dynamic set. (Comments on the feasibility of my idea from portage people appreciated) Currently, users with Portage have to run something like: ~ emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \ ~compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \ ~emerald emerald-themes libcompizconfig compizconfig-python \ ~ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \ ~compiz-fusion fusion-icon That is the situation where you really love the sets in portage 2.2 - by default portage will re-merge every ebuild from a set when run as "emerge @your-custom-set". Now the overlay maintainer just has to provide the sets with the overlay and users are happy. The problem with the - ebuilds is that we need to force manually the reinstalls and that the PM isn't able to determine if a dep needs to be updated or not from the ebuild revision. If you use sets the updating part is easy, and in situations like emerge -e world you want to update them anyway. So, running a reinstall with a world update is not desirable and having to manually mask/unmask live ebuilds can also be a mess. I don't follow - if you want to update everything everything gets upgraded. What you seem to want is a way to make certain revisions "sticky" so that they don't get updated, that would need something like a "package.revisions" file like package.keywords containing "category/package revision" lines. Having a method that lets the user choose to reinstall all the live ebuilds every N days is an interesting option. Having a method that lets the user choose that the PM should check the scm tree and update the package if there's a new revision would be even better. I think that can be easily done if there's an easy way to pull the installed revision and currently available. The last discussions about that stalled without reaching agreement. But for most cases, if we define a method to identify "live" ebuilds so that the PM can implement a "--dl-reinstall-scm" like option, would be "good enough" or at least a "very good start". I agree Another case where having a method to let PMs identify "live" ebuilds is important is for running QA scripts like repoman or pcheck. Instead of having pcheck complain about dropped keywords for version , I would like to have pcheck complain about "live" ebuilds with keywords. Not all "live" trees are unstable and thus some might not like this change. However, if a PM is able to determine "live" ebuilds, it might be easier to have alternative tests that allow testing for dropped keywords or for the existence of keywords just for "live" ebuilds. That's what metadata is there for. And ebuilds don't mind carrying a bit more ... after all it's just one line of text. So, what you want to do is to read every ebuild, if you want to find all live ebuilds? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Packages broken by phase ordering change
On Fri, 13 Jun 2008 21:55:29 +0200 "Santiago M. Mola" <[EMAIL PROTECTED]> wrote: > As discussed in bug #222721, portage has changed the execution order > of phases. It seems the change was introduced in portage-2.1.5 and it > makes that, when upgrading a package, pkg_postinst is run after the > old version has been removed. This breaks packages which use > has_version in pkg_postinst to detect upgrades/downgrades. It can also > break packages in more subtle ways. Given that the number of affected ebuilds is so high, I'd say Portage should have to revert the changes... This is an EAPI scope change, if anything. Although even then the implications are a bit messy since you're talking the interaction of two different EAPIs. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Luca Barbato schrieb: Santiago M. Mola wrote: On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato <[EMAIL PROTECTED]> wrote: Ryan Hill wrote: I'm guessing the dev would need to change 0.26.live to 0.26.1.live when 0.26 was released. I already need to do this with my live ebuilds. Of course, with some projects you never know if the next version will be 0.26.1, 0.27, or 0.3, or 1.0... That's an upstream issue, all we should care is about getting a version value that makes sense for us, better if it does for them. I think upstream use release branches correctly here, and it's the most widespread use. There's some real examples where ".live" = "_pre" has problems. * media-video/mplayer: I'd expect 1.0.live to be higher than 1.0_rc2, but it doesn't. I'd also expect 1.0.live to be higher than 1.0 when it's released. MPlayer has a psychological issue with 1.0 versioning, still 1.0.live correctly isn't higher than 1.0 No, it is not. Take KDE for example, they have trunk currently, that will become KDE 4.1.0. When that has been released, there will be a branch 4.1, which is ahead of 4.1.0 and will become 4.1.1, then 4.1.2 (when 4.1.1 has been released) etc. In the -scm approach this means: trunk = -scm 4.1 branch = -4.1-scm With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: trunk = .live 4.1 branch = 4.1.1.live (before 4.1.1 has been released) 4.1 branch = 4.1.2.live (before 4.1.2 has been released) 4.1 branch = 4.1.3.live (before 4.1.3 has been released) ... -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 15:29:00 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > Which of the issues I listed needs to be addressed for the scm > > proposal? > > At least the upstream server load. -scm doesn't attempt to use upstream to obtain any information. Upstream is only contacted when people install or reinstall packages, the same as for - versions currently. > Other people seem to think it's feasible Jumping to that conclusion from such a vague proposal suggests that not much thought has gone into thinking that... > I think my proposal nicer and giving some value for the effort of > implementing it And I think it's not even far enough to be called a proposal, and we can't sensibly discuss any of it until it is. > -scm adds a some work to do with undefined features at best. -scm is trivial. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 15:25:53 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > * What generation looks like. > > Mostly implementation detail? Somebody seems to have ideas there and > I like to heard ideas from others as well. It's not a detail. It's extremely important, and we can't discuss this sanely until we have detailed proposals for this. > > * How to select which ebuilds to trigger generation for. > > I'm fond of sets and I'd extend maint to be feeded to sets other than > world and all. Again, details. > > * When specifically to trigger generation. > > User decision or triggered by sync depending on a FEATURE. Again, details. This one *really* needs to be worked out, since it's getting in the way of discussing other implications. > > * The security implications of the previous point. > > None? Well, generated revision numbers may have to be stored somewhere. Should a normal user be able to force a generation? If not, this means having to generate templates at sync time for every scm package in the tree, which in turn means scanning every ebuild in the tree. > > * What the impact upon upstream servers is, if any. > > Shared with glep 54 GLEP 54 doesn't use upstream scm revision information at all. Are you definitely saying that your proposal will not be tied in to upstream revisions in any way? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: Which of the issues I listed needs to be addressed for the scm proposal? At least the upstream server load. Ok, here's the best help I can give you: Your proposal can't work. You can't get correct ordering reusing existing components. You can't get sane behaviour using your template scheme without making it aware of scm revisions. You can't make it scm revision aware without a hell of a lot of work. And if you do want to make it scm revision aware, you need changes to the version scheme anyway. Other people seem to think it's feasible, I think my proposal nicer and giving some value for the effort of implementing it, -scm adds a some work to do with undefined features at best. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: * What generation looks like. Mostly implementation detail? Somebody seems to have ideas there and I like to heard ideas from others as well. * How to select which ebuilds to trigger generation for. I'm fond of sets and I'd extend maint to be feeded to sets other than world and all. * When specifically to trigger generation. User decision or triggered by sync depending on a FEATURE. * Whether generation failure is possible, and what happens if it is. I could think easily that such thing could happen (no network is a possibility) * What to do when generated information is required but not available. Consider the ebuild corrupted or do not generate it. * The security implications of the previous point. None? * What the impact upon upstream servers is, if any. Shared with glep 54 * How generation fits in with users doing system updates. Orthogonal * How generation fits in with the highly differing frequencies of upstream updates. Being user driven isn't an issue at all. * How generation can be made to fit in without changes to the version spec, whilst still 'making sense' and doing the right thing. Discussion going on in this thread, so far Coldwind did quite well to pointing actual cases present in portage already, discussion on them should help sorting out issues. Using live sources is a security and stability concern by itself and by accepting that you are at the very end of the bleeding edge you acknowledge that you are experimenting. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 15:15:45 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Sat, 14 Jun 2008 14:27:22 +0200 > > Luca Barbato <[EMAIL PROTECTED]> wrote: > >> Many of them applies as well to the alternative proposal, I wonder > >> how you could say we, council, had to vote the other proposal given > >> such (and other) issues were open. > > > > No they don't. > > False. Which of the issues I listed needs to be addressed for the scm proposal? > > Does this mean you don't have answers then? > > From start I asked for help and from start I said that my proposal > is anything but complete. I have no delusion to have all the answers > at hand anytime. Ok, here's the best help I can give you: Your proposal can't work. You can't get correct ordering reusing existing components. You can't get sane behaviour using your template scheme without making it aware of scm revisions. You can't make it scm revision aware without a hell of a lot of work. And if you do want to make it scm revision aware, you need changes to the version scheme anyway. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: On Sat, 14 Jun 2008 14:27:22 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: Many of them applies as well to the alternative proposal, I wonder how you could say we, council, had to vote the other proposal given such (and other) issues were open. No they don't. False. Does this mean you don't have answers then? From start I asked for help and from start I said that my proposal is anything but complete. I have no delusion to have all the answers at hand anytime. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: A few questions to our nominees
Jorge Manuel B. S. Vicetto wrote: Those using paludis need just to run[1]: ~ paludis -pi1 compiz-fusion --dl-reinstall-scm always --compact \ ~--show-reasons none and what about # emerge @compiz [1] Simpler isn't it? Or # emaint -r world[2] # emerge -u compiz-fusion [1] you you can do that right now. [2] possible way to trigger regeneration, extended to sets if interesting. So, running a reinstall with a world update is not desirable and having to manually mask/unmask live ebuilds can also be a mess. Agreed. Having a method that lets the user choose to reinstall all the live ebuilds every N days is an interesting option. Having a method that lets the user choose that the PM should check the scm tree and update the package if there's a new revision would be even better. so something like #emerge -uL compiz-fusion is what you'd like better. One option that might be interesting to avoid having the PM update *all* live deps, would be to have an option to run the update for packages inside a set. In this case, for example, I could just add all the compiz packages to a set and not worry about the PM updating also all the live kde packages. right now you can add all the compiz packages to a set and just issue and emerge @compiz and archive what you want ^^ Another case where having a method to let PMs identify "live" ebuilds is important is for running QA scripts like repoman or pcheck. Instead of having pcheck complain about dropped keywords for version , I would like to have pcheck complain about "live" ebuilds with keywords. Not all "live" trees are unstable and thus some might not like this change. However, if a PM is able to determine "live" ebuilds, it might be easier to have alternative tests that allow testing for dropped keywords or for the existence of keywords just for "live" ebuilds. Agreed. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 14:27:22 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Many of them applies as well to the alternative proposal, I wonder > how you could say we, council, had to vote the other proposal given > such (and other) issues were open. No they don't. The alternative proposal is deliberately simple enough to avoid those issues, whilst leaving the possibility of a larger solution that does have scm revision awareness open for the future. Does this mean you don't have answers then? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Santiago M. Mola wrote: On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato <[EMAIL PROTECTED]> wrote: Ryan Hill wrote: I'm guessing the dev would need to change 0.26.live to 0.26.1.live when 0.26 was released. I already need to do this with my live ebuilds. Of course, with some projects you never know if the next version will be 0.26.1, 0.27, or 0.3, or 1.0... That's an upstream issue, all we should care is about getting a version value that makes sense for us, better if it does for them. I think upstream use release branches correctly here, and it's the most widespread use. There's some real examples where ".live" = "_pre" has problems. * media-video/mplayer: I'd expect 1.0.live to be higher than 1.0_rc2, but it doesn't. I'd also expect 1.0.live to be higher than 1.0 when it's released. MPlayer has a psychological issue with 1.0 versioning, still 1.0.live correctly isn't higher than 1.0 * media-video/ffmpeg: Pretty much the same that mplayer, but a bit worse. No, ffmpeg does "continuous release" every commit must not add regressions and the ABI/API is marked, a correct version for ffmpeg is given by taking the combination of the libraries major version. Every major version update I'll have to update the live ebuild because of that and this is correct. * x11-wm/enlightenment: latest release is 0.16.8.13, current live ebuild is 0.16.. If we use ".live" here we'd need either 0.16..live (which is quite pointless) or 0.16.8.14.live which would need to be updated after every minor release. 0.17.live is not a possibility at all since 0.17 is a rewrite from scratch and an entire different application. 0.16.9.live sounds that bad? With the current proposal, .live ebuilds should be changed after every minor release, unless we use the number of the next release. You do pick what is good for you. Next release isn't always known, and it's doesn't always make sense. This puts us in a worse situation than with GLEP 54, or even with the current use of . components. I don't see how. Keep in mind that - ebuild should just stay in overlay and shouldn't be used by average users. The should help us developer tracking projects and get us to the point of having a snapshot for common usage. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: A few questions to our nominees
On Saturday 14 June 2008 11:53:51 Jorge Manuel B. S. Vicetto wrote: > What's the need for a GLEP covering "live" ebuilds and what's wrong with > - ebuilds? I made myself that question when GLEP54 was submitted and > during the initial discussion. At that time, I wasn't convinced of the > need for such a GLEP. Now I think it can be very useful. > Why did I change my mind? Let's have a concrete use case. > > Updating the live ebuilds for compiz, can be a mess. If the ebuilds > aren't updated in the correct order, the process will fail and leave > users wondering why it failed. What we need is a way to ask the PM to > update compiz-fusion and or fusion-icon and all its "live" deps. Ok, here's a silly idea - tag the ebuilds with metadata. We already have RESTRICT, why not add a "LIVE" variable. The package manager can then treat all ebuilds with that tag differently. Scripts can find them easily. It is forwards and backwards compatible and doesn't cause any user-visible changes. Portage 2.2 and others support sets, portage 2.2 even supports dynamic sets like the "@preserved-rebuild". Shouldn't be that hard to add a "live-ebuilds" dynamic set. (Comments on the feasibility of my idea from portage people appreciated) > Currently, users with Portage have to run something like: > ~ emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \ > ~compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \ > ~emerald emerald-themes libcompizconfig compizconfig-python \ > ~ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \ > ~compiz-fusion fusion-icon That is the situation where you really love the sets in portage 2.2 - by default portage will re-merge every ebuild from a set when run as "emerge @your-custom-set". Now the overlay maintainer just has to provide the sets with the overlay and users are happy. > The problem with the - ebuilds is that we need to force manually the > reinstalls and that the PM isn't able to determine if a dep needs to be > updated or not from the ebuild revision. If you use sets the updating part is easy, and in situations like emerge -e world you want to update them anyway. > So, running a reinstall with a world update is not desirable and having > to manually mask/unmask live ebuilds can also be a mess. I don't follow - if you want to update everything everything gets upgraded. What you seem to want is a way to make certain revisions "sticky" so that they don't get updated, that would need something like a "package.revisions" file like package.keywords containing "category/package revision" lines. > Having a method that lets the user choose to reinstall all the live > ebuilds every N days is an interesting option. Having a method that lets > the user choose that the PM should check the scm tree and update the > package if there's a new revision would be even better. I think that can be easily done if there's an easy way to pull the installed revision and currently available. The last discussions about that stalled without reaching agreement. > But for most cases, if we define a method to identify "live" ebuilds so > that the PM can implement a "--dl-reinstall-scm" like option, would be > "good enough" or at least a "very good start". I agree > Another case where having a method to let PMs identify "live" ebuilds is > important is for running QA scripts like repoman or pcheck. > Instead of having pcheck complain about dropped keywords for version > , I would like to have pcheck complain about "live" ebuilds with > keywords. Not all "live" trees are unstable and thus some might not like > this change. However, if a PM is able to determine "live" ebuilds, it > might be easier to have alternative tests that allow testing for dropped > keywords or for the existence of keywords just for "live" ebuilds. That's what metadata is there for. And ebuilds don't mind carrying a bit more ... after all it's just one line of text. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: * What generation looks like. * How to select which ebuilds to trigger generation for. * When specifically to trigger generation. * Whether generation failure is possible, and what happens if it is. * What to do when generated information is required but not available. * The security implications of the previous point. * What the impact upon upstream servers is, if any. * How generation fits in with users doing system updates. * How generation fits in with the highly differing frequencies of upstream updates. * How generation can be made to fit in without changes to the version spec, whilst still 'making sense' and doing the right thing. The answers to all of the above are highly non-trivial. Many of them applies as well to the alternative proposal, I wonder how you could say we, council, had to vote the other proposal given such (and other) issues were open. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: A few questions to our nominees
"Santiago M. Mola" <[EMAIL PROTECTED]> writes: > * media-sound/amarok: live version is 1.4.. Next version is 2.0, > but that's a different branch so I'd expect 2.0.live to give me the > latest 2.0 version available, not 1.4's. 1.4. has been switched from because of the 2.0/1.4 branches, would be 2.0 (if I ever care enough to add that, not before a beta is released for sure, and not before I can use KDE 4.1 daily, which is not something I expect to happen soonish). Just FYI. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpvaSuTaiUhN.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: A few questions to our nominees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What's the need for a GLEP covering "live" ebuilds and what's wrong with - - ebuilds? I made myself that question when GLEP54 was submitted and during the initial discussion. At that time, I wasn't convinced of the need for such a GLEP. Now I think it can be very useful. Why did I change my mind? Let's have a concrete use case. Updating the live ebuilds for compiz, can be a mess. If the ebuilds aren't updated in the correct order, the process will fail and leave users wondering why it failed. What we need is a way to ask the PM to update compiz-fusion and or fusion-icon and all its "live" deps. Currently, users with Portage have to run something like: ~ emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \ ~compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \ ~emerald emerald-themes libcompizconfig compizconfig-python \ ~ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \ ~compiz-fusion fusion-icon Those using paludis need just to run[1]: ~ paludis -pi1 compiz-fusion --dl-reinstall-scm always --compact \ ~--show-reasons none [1] - I don't run paludis myself. That command is what some paludis users run to update the compiz ebuilds. The problem with the - ebuilds is that we need to force manually the reinstalls and that the PM isn't able to determine if a dep needs to be updated or not from the ebuild revision. Tiziano Müller wrote: | Luca Barbato wrote: | |> Tiziano Müller wrote: |>> @lu_zero: I don't think we can get away without having the pm know what a |>> live-ebuild exactly is and when to re-install it. |> a live ebuild is a template, every time it has to be evaluated it acts |> as a normal ebuild with the version mentioned and _preN+1 postponed, |> preN is the highest preN present, if present. | Sorry, but I don't want to re-install a snapshot every time I do a world | update. And I also don't want to manually mask/unmask the live ebuilds. | I either want to be able to specify a time interval after which live ebuilds | should be refetched or being able to manually re-install them (second use | case is trivial). | So, running a reinstall with a world update is not desirable and having to manually mask/unmask live ebuilds can also be a mess. Having a method that lets the user choose to reinstall all the live ebuilds every N days is an interesting option. Having a method that lets the user choose that the PM should check the scm tree and update the package if there's a new revision would be even better. But for most cases, if we define a method to identify "live" ebuilds so that the PM can implement a "--dl-reinstall-scm" like option, would be "good enough" or at least a "very good start". One option that might be interesting to avoid having the PM update *all* live deps, would be to have an option to run the update for packages inside a set. In this case, for example, I could just add all the compiz packages to a set and not worry about the PM updating also all the live kde packages. Another case where having a method to let PMs identify "live" ebuilds is important is for running QA scripts like repoman or pcheck. Instead of having pcheck complain about dropped keywords for version , I would like to have pcheck complain about "live" ebuilds with keywords. Not all "live" trees are unstable and thus some might not like this change. However, if a PM is able to determine "live" ebuilds, it might be easier to have alternative tests that allow testing for dropped keywords or for the existence of keywords just for "live" ebuilds. - -- 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 iEYEARECAAYFAkhTsU8ACgkQcAWygvVEyAK5JwCfQlflTUNi9hDcUgwgxgAyUbS6 lakAoJhyQG4KsnyfRJez6edhuKQmVVOL =y7PF -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato <[EMAIL PROTECTED]> wrote: > Ryan Hill wrote: >> >> I'm guessing the dev would need to change 0.26.live to 0.26.1.live when >> 0.26 was released. I already need to do this with my live ebuilds. Of >> course, with some projects you never know if the next version will be >> 0.26.1, 0.27, or 0.3, or 1.0... > > That's an upstream issue, all we should care is about getting a version > value that makes sense for us, better if it does for them. > I think upstream use release branches correctly here, and it's the most widespread use. There's some real examples where ".live" = "_pre" has problems. * media-video/mplayer: I'd expect 1.0.live to be higher than 1.0_rc2, but it doesn't. I'd also expect 1.0.live to be higher than 1.0 when it's released. * media-video/ffmpeg: Pretty much the same that mplayer, but a bit worse. * x11-wm/enlightenment: latest release is 0.16.8.13, current live ebuild is 0.16.. If we use ".live" here we'd need either 0.16..live (which is quite pointless) or 0.16.8.14.live which would need to be updated after every minor release. 0.17.live is not a possibility at all since 0.17 is a rewrite from scratch and an entire different application. * media-sound/amarok: live version is 1.4.. Next version is 2.0, but that's a different branch so I'd expect 2.0.live to give me the latest 2.0 version available, not 1.4's. With the current proposal, .live ebuilds should be changed after every minor release, unless we use the number of the next release. Next release isn't always known, and it's doesn't always make sense. This puts us in a worse situation than with GLEP 54, or even with the current use of . components. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 12:45:31 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > > And none of those are even close to a reasonable, implementable > > idea. > > They are implementable. They're really not. You haven't even begun to discuss: * What generation looks like. * How to select which ebuilds to trigger generation for. * When specifically to trigger generation. * Whether generation failure is possible, and what happens if it is. * What to do when generated information is required but not available. * The security implications of the previous point. * What the impact upon upstream servers is, if any. * How generation fits in with users doing system updates. * How generation fits in with the highly differing frequencies of upstream updates. * How generation can be made to fit in without changes to the version spec, whilst still 'making sense' and doing the right thing. The answers to all of the above are highly non-trivial. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: On Sat, 14 Jun 2008 12:04:45 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: It will be available once you trigger again the generation or if you put a normal ebuild with such name. And what triggers said generation? I already replied in this thread, I guess the information is getting too spread (and will be a pain put it back to the glep) =/ dev-zero pointed out that he would like to trigger the generation on a timely basis, I wanted to trigger it on the sync event, others had other opinion, so the best would be have it as separate phase and trigger it from the maint application. And none of those are even close to a reasonable, implementable idea. They are implementable. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 12:04:45 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > >> It will be available once you trigger again the generation or if > >> you put a normal ebuild with such name. > > > > And what triggers said generation? > > I already replied in this thread, I guess the information is getting > too spread (and will be a pain put it back to the glep) =/ > > dev-zero pointed out that he would like to trigger the generation on > a timely basis, I wanted to trigger it on the sync event, others had > other opinion, so the best would be have it as separate phase and > trigger it from the maint application. And none of those are even close to a reasonable, implementable idea. I'm getting the impression you really didn't think this through at all before mailing your proposal. I suggest you go back to the start, work out use cases, package manager interactions, how if at all ebuilds will need to be adapted and several examples. There's a big difference between a few vague ideas and the foundations for an implementable proposal. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: On Sat, 14 Jun 2008 11:53:51 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: Ciaran McCreesh wrote: On Sat, 14 Jun 2008 10:19:32 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev. 136737, after the merge do I have gcc-4.4.0_pre136737 or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) installed? it would be gcc-4.4.0_pre1 but you'll have the revision inside the ebuild as var so you can get it easily. (e.g. the description shows it) And when would gcc-4.4.0_pre2 become available? It will be available once you trigger again the generation or if you put a normal ebuild with such name. And what triggers said generation? I already replied in this thread, I guess the information is getting too spread (and will be a pain put it back to the glep) =/ dev-zero pointed out that he would like to trigger the generation on a timely basis, I wanted to trigger it on the sync event, others had other opinion, so the best would be have it as separate phase and trigger it from the maint application. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 11:53:51 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Sat, 14 Jun 2008 10:19:32 +0200 > > Luca Barbato <[EMAIL PROTECTED]> wrote: > >>> I'm confused. If I have a gcc-4.4.0.live ebuild which checks out > >>> rev. 136737, after the merge do I have gcc-4.4.0_pre136737 > >>> or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) > >>> installed? > >> it would be gcc-4.4.0_pre1 but you'll have the revision inside the > >> ebuild as var so you can get it easily. (e.g. the description shows > >> it) > > > > And when would gcc-4.4.0_pre2 become available? > > It will be available once you trigger again the generation or if you > put a normal ebuild with such name. And what triggers said generation? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: On Sat, 14 Jun 2008 10:19:32 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev. 136737, after the merge do I have gcc-4.4.0_pre136737 or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) installed? it would be gcc-4.4.0_pre1 but you'll have the revision inside the ebuild as var so you can get it easily. (e.g. the description shows it) And when would gcc-4.4.0_pre2 become available? It will be available once you trigger again the generation or if you put a normal ebuild with such name. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] eapi1 bug/pkgcore sucks thread [was EAPI-2 - Let's get it started]
On Thu, 2008-06-12 at 11:39 +0200, Fernando J. Pereda wrote: > On 12 Jun 2008, at 04:16, Brian Harring wrote: > > > > Why the exherbo/paludis/PMS folk decided to go this route to report, > > I'm not quite sure aside from assuming they're just griefers. > > s-exherbo/paludis/PMS-pkgcore-g and: > > http://fpereda.wordpress.com/2008/05/03/on-cooperating-and-paludis-vulnerability/ > > Except this one wasn't a lie. > > I wish there were more cooperation between all of us. But looks like > it is impossible with some of your people. > > - ferdy > Please stop whoring the url for that, its old already. There is a huge difference between that and knowingly witholding information because you "want to see unit tests done." Quit being a fuckwit. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Marius Mauch wrote: Ignoring possible semantic issues for the moment, Please point them so I could fix them properly ^^ I'd be against this simply because it would require the PM to be aware of the current revision of the repository and to transform it into a integer value (trivial for SVN, not so trivial for CVS for example). You should be able to have a generic framework that just uses what the ebuild needs to get the sources, standardizing the live eclasses will be enough. Which in turn either means that the PM has to internally support the SCMs or support some new phase functions to extract the revision. After some discussions with dev-zero, I think we'll need a new phase, possibly trigged by maint, before I was thinking about adding it to sync. Plus it has similar (unstated) transition issues as GLEP-54, just avoids a new comparison algorithm and the CPV vs. atom issue. Hmm, give me more informations about your concern. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 10:19:32 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > > I'm confused. If I have a gcc-4.4.0.live ebuild which checks out > > rev. 136737, after the merge do I have gcc-4.4.0_pre136737 > > or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) > > installed? > > it would be gcc-4.4.0_pre1 but you'll have the revision inside the > ebuild as var so you can get it easily. (e.g. the description shows > it) And when would gcc-4.4.0_pre2 become available? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Ryan Hill wrote: On Fri, 13 Jun 2008 13:35:52 +0200 Marius Mauch <[EMAIL PROTECTED]> wrote: Ignoring possible semantic issues for the moment, I'd be against this simply because it would require the PM to be aware of the current revision of the repository and to transform it into a integer value (trivial for SVN, not so trivial for CVS for example). Which in turn either means that the PM has to internally support the SCMs or support some new phase functions to extract the revision. I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev. 136737, after the merge do I have gcc-4.4.0_pre136737 or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) installed? it would be gcc-4.4.0_pre1 but you'll have the revision inside the ebuild as var so you can get it easily. (e.g. the description shows it) The former, as Marius said, requires knowledge of how to get a sane revision id from every SCM we want to support to be built into the package manager. I wonder if instead of rev id, we could use a timestamp to fill in _pre. It's not ideal but it narrows the checkout down somewhat. Also, we could use pkg_info to report revision numbers (for those SCM's that have such a thing). The combination of the two might be enough - you'd have the revision you installed, when you installed it, and an automatic incrementor for those ppl who like those kinds of things. I like better single digits but it's more or less the same as structure and code. If a dev wants to force a reinstall because of ebuild or patch changes or whatever, they should still be able to use -rX as usual. A lot of projects work like this: * trunk/ is current development, and is ahead of any release. * branches/0.26/ is forked from trunk/ when 0.26 is released, and is equal to or ahead of any 0.26 release. How does your proposal handle this? I'm guessing the dev would need to change 0.26.live to 0.26.1.live when 0.26 was released. I already need to do this with my live ebuilds. Of course, with some projects you never know if the next version will be 0.26.1, 0.27, or 0.3, or 1.0... That's an upstream issue, all we should care is about getting a version value that makes sense for us, better if it does for them. As for an ebuild tracking trunk, I guess we're back to -.live. ;P or just keep in mind that even trunk changes enough that you need to update the ebuild thus makes sense use a next supposed version. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
