Re: [gentoo-dev] repoman complains about a ebuild in the tree
Nirbheek Chauhan nirbh...@gentoo.org wrote:
That's because repoman is context-aware. When you use it, it'll look
around (../..) the current directory for the dependencies. If it
finds the deps, it'll check if the ebuilds. If can't find the
dependencies, it'll look in ${PORTDIR} for checking them.
Thanks. I really haven't updated the whole cvs tree (because it takes sooo
lng), only the category (sci-visualization). I thought that the main
(rsync) tree is used for dependences.
cvs-updating ~/gentoo-x86 solved the problem.
Andrey
[gentoo-dev] QA last rites for app-i18n/dbskkd-cdb-2; app-i18n/skk-jisyo-cdb; app-i18n/skk-jisyo-extra
# Diego E. Pettenò flamee...@gentoo.org (14 Sep 2009) # on behalf of QA team # # Replaced by app-i18n/skk-jisyo (with cdb USE flag); old # and stale. # # Removal on 2009-11-13 app-i18n/dbskkd-cdb-2 app-i18n/skk-jisyo-cdb app-i18n/skk-jisyo-extra
[gentoo-dev] QA last rites for app-forensics/pyflag
# Diego E. Pettenò flamee...@gentoo.org (14 Sep 2009) # on behalf of QA team # # Fails to build for over an year, see bug #233089 opened # in July 2008. # # Removal on 2009-11-13 app-forensics/pyflag
Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]
On Sun, 13 Sep 2009 22:17:19 +0200 Sebastian Pipping webmas...@hartwork.org wrote: Ciaran McCreesh wrote: Not quite. If both an overlay and the main tree provide foo-1.2, masking foo-1.2::overlay in Portage would end up masking every foo-1.2. Why? Because an overlay model has only a single foo-1.2. Think of it like stacks of paper. You've got your main repository: ::gentoofoo-1.1 foo-1.2 foo-1.3 and on top of that you put your overlay: ::extras foo-1.2 foo-1.4 ::gentoo foo-1.1 foo-1.2 foo-1.3 and then looking down from the top, all an overlay model package manager sees is the foo-1.2 from the overlay. There's no foo-1.2::gentoo and foo-1.2::extras, there's just a single foo-1.2 that's made from (gentoo + extras). There's a different way of looking at it that focuses more on the repository level view at [1]. [1]: http://ciaranm.wordpress.com/2009/04/16/distributed-distribution-development-and-why-git-and-or-funtoo-is-not-it/ -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]
Ciaran McCreesh wrote: Because an overlay model has only a single foo-1.2. Think of it like stacks of paper. You've got your main repository: ::gentoofoo-1.1 foo-1.2 foo-1.3 and on top of that you put your overlay: ::extras foo-1.2 foo-1.4 ::gentoo foo-1.1 foo-1.2 foo-1.3 and then looking down from the top, all an overlay model package manager sees is the foo-1.2 from the overlay. There's no foo-1.2::gentoo and foo-1.2::extras, there's just a single foo-1.2 that's made from (gentoo + extras). I see. So it would not work for dependencies but it should work for masking. That alone wouldn't make me happy, though. There's a different way of looking at it that focuses more on the repository level view at [1]. [1]: http://ciaranm.wordpress.com/2009/04/16/distributed-distribution-development-and-why-git-and-or-funtoo-is-not-it/ Interesting read. Can you think of anything technical that would make moving portage to this model impossible? Sebastian
Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]
On Mon, 14 Sep 2009 20:28:26 +0200 Sebastian Pipping webmas...@hartwork.org wrote: Ciaran McCreesh wrote: Because an overlay model has only a single foo-1.2. Think of it like stacks of paper. You've got your main repository: ::gentoofoo-1.1 foo-1.2 foo-1.3 and on top of that you put your overlay: ::extras foo-1.2 foo-1.4 ::gentoo foo-1.1 foo-1.2 foo-1.3 and then looking down from the top, all an overlay model package manager sees is the foo-1.2 from the overlay. There's no foo-1.2::gentoo and foo-1.2::extras, there's just a single foo-1.2 that's made from (gentoo + extras). I see. So it would not work for dependencies but it should work for masking. That alone wouldn't make me happy, though. I don't think it would necessarily work for masking either the way Portage sees it (although iirc it would have done for the way Pkgcore did things). Masking doesn't make foo-1.2::extras invisible, it just makes it visible but unusable. Even if you do take the ignore masked things entirely approach, the behaviour's highly weird when things like repository package.masks become involved -- I'm not sure you could define a consistent model that does 'the right thing' purely on overlays (although feel free to try...). There's a different way of looking at it that focuses more on the repository level view at [1]. [1]: http://ciaranm.wordpress.com/2009/04/16/distributed-distribution-development-and-why-git-and-or-funtoo-is-not-it/ Interesting read. Can you think of anything technical that would make moving portage to this model impossible? Other than the usual problems with moving Portage to things? No. The multiple repository model works fine with Gentoo, and it's possible to set it up so that it looks to the user exactly like an overlay model except where ::repo deps are involved. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] overlay usage and maintainence [was: DistroWatch and Gentoo packages: status quo and future]
Sebastian Pipping wrote: Ciaran McCreesh wrote: Because an overlay model has only a single foo-1.2. Think of it like stacks of paper. You've got your main repository: ::gentoofoo-1.1 foo-1.2 foo-1.3 and on top of that you put your overlay: ::extras foo-1.2 foo-1.4 ::gentoo foo-1.1 foo-1.2 foo-1.3 and then looking down from the top, all an overlay model package manager sees is the foo-1.2 from the overlay. There's no foo-1.2::gentoo and foo-1.2::extras, there's just a single foo-1.2 that's made from (gentoo + extras). I see. So it would not work for dependencies but it should work for masking. That alone wouldn't make me happy, though. There's a different way of looking at it that focuses more on the repository level view at [1]. [1]: http://ciaranm.wordpress.com/2009/04/16/distributed-distribution-development-and-why-git-and-or-funtoo-is-not-it/ Interesting read. Can you think of anything technical that would make moving portage to this model impossible? It shouldn't be too difficult to tweak portage so that multiple ebuilds of the same version from different repositories are visible to portage's dependency resolver. Currently, it uses a collection of 3 repositories to resolve dependencies: installed, ebuild, and binary packages. Replacing the single ebuild repository (portdbapi class) instance with multiple instances, one for each overlay, should produce the desired result. -- Thanks, Zac
