Re: [gentoo-dev] What are blocks used for?
Enrico Weigelt wrote: * Ciaran McCreesh <[EMAIL PROTECTED]> schrieb: Hi, Hi Enrico, long time no see! b) Marking that two related implementations are mutually incompatible at runtime because they both provide the same binary. Classical example: MTA's: Traditionally they tend to provide an /usr/sbin/sendmail executable. So you can't have multiple MTAs installed. Here the problem isn't that portage can't give more advise, but the system only allows I see you've been missing this list for a long time. Today it's not politically correct to say bluntly "portage" but "package manager" (PM)! For example, for class d) blocks such as the recent coreutils / mktemp mess, Yes, this is *really* a mess, especially because critical packages are involved here. IMHO the problem is clearly made by the two packages themselves. Actually I didn't track yet who was first, but according to the ebuilds, the conflict arises w/ 6.10 (not yet in 6.9). IMHO the external mktemp should be preferred and the coreutils's one skipped. Um no, we should not stick with packages forever for historical reasons. the package manager can suggest to the user to install the new package and then uninstall the old package, rather than forcing the user to uninstall the old package by hand (possibly leaving their system without critical utilities) and then install the new package. Yes, but this requires the ebuild author to provide enough information *very carefully*. Yes, ebuild author should be careful, OTOH the end users wouldn't have to be as much careful as they had to be now when dealing with it themselves. In this specific case, portage could automatically decide to replace the separate mktemp package by newer coreutils. But what happens if some package depends on the mktemp package ? Such deps should obviously be transformed to || ( >=coreutils-6.10 mktemp) beforehand. Portage has to catch these deps and map them to coreutils if they provide mktemp (and only for those versions which *really do*). No, it should probably just state there's a dep conflict (as it does now if there are several depends asking for different versions inside one slot). This all adds a lot of complexity, and I doubt it's really worth it. Stating dep conflict should be less complexity, and yes it's worth it. Removing mktemp and properly maintaining the standalone package seems much easier and cleaner to me. Sure, legacy and maintainership burden ftw! I'm tempted to say "we are not debian" but since I'm not council... :( Caster -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] PostgreSQL Status
Enrico Weigelt wrote:
* Luca Barbato <[EMAIL PROTECTED]> schrieb:
Tiziano Müller wrote:
What do the new ebuilds offer:
a) A split into dev-db/postgresql-{base,server,docs}.
WRONG we aren't debian.
It's bad, just because Debian does it ?!
Sounds quite religions to me. I don't like religions interfering with
technical designs.
Other way round.
Gentoo has useflags to provide what binary distribution (debian pointed
as its one of the best in their field) do by butchering the packages.
The only good reason to split a package is if takes too much to build
and you have a clean way to do that (e.g qemu and kde) (then we provide
meta packages to give back what people expect from emerge foo)
If upstream package its stuff in a way it's better to work with them to
accomodate different needs, butchering leads to annoyance on our side
and their.
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] Linux 2.6.25 info
Daniel Drake wrote: 2.6.25 was released today, gentoo-sources-2.6.25 is now in portage. As usual this will break some packages in the portage tree (ones that include kernel code), the tracker for such issues is here: http://bugs.gentoo.org/show_bug.cgi?id=218127 Jakub normally does a wonderful job of herding all such bugs, but it looks like he isn't around at the moment. Please help out by adding your bugs there, assuming that your package is in the stable tree and the current stable one works on 2.6.24. As usual I hope to start thinking about 2.6.25 stabling in 3 weeks time (that'll be May 8th) but this is of course subject to the state of affairs when we get that far :) Daniel People using ati-drivers (and possibly other external drivers) as usual do not upgrade if you aren't ready to help fixing the drivers. ^^ 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: PostgreSQL Status
Tiziano Müller wrote: Luca Barbato wrote: It gives an annoyance please reconsider. Done that. Won't change. See my answer to dberkholz's message. As long you keep a meta package, as you told in the reply I read just now, seems a good plan in the end. 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] Dependencies that're available at pkg_*inst
I'm rewording the PMS sections on dependencies to avoid permitting overly lax circular dependency resolution. Which of these wordings is accurate, given that usable means "has its RDEPENDs installed and usable"? 1. During pkg_preinst and pkg_postinst, any package dependency that is in both DEPEND and RDEPEND must be installed and usable. 2. During pkg_preinst and pkg_postinst, at least one of the following conditions must be met: a. every package dependency in DEPEND must be installed and usable b. every package dependency in RDEPEND must be installed and usable Do not attempt to write on both sides of the paper at once. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On 05:31 Sat 19 Apr , Ciaran McCreesh wrote: > I'm rewording the PMS sections on dependencies to avoid permitting > overly lax circular dependency resolution. Which of these wordings is > accurate, given that usable means "has its RDEPENDs installed and > usable"? > > 1. During pkg_preinst and pkg_postinst, any package dependency that is > in both DEPEND and RDEPEND must be installed and usable. > > 2. During pkg_preinst and pkg_postinst, at least one of the following > conditions must be met: > a. every package dependency in DEPEND must be installed and usable > b. every package dependency in RDEPEND must be installed and usable I'd go with RDEPEND only. Any other interpretation results in installing build-time-only packages along with a binpkg, which doesn't seem to make sense. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Fri, 18 Apr 2008 21:45:13 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > I'd go with RDEPEND only. Any other interpretation results in > installing build-time-only packages along with a binpkg, which > doesn't seem to make sense. That's definitely not what we want. Only a package's DEPENDs have to be installed and usable when that package is built. Its RDEPENDs don't have to be installed until that package is treated as usable. For why this matters: cat/a-1: RDEPEND cat/b cat/b-1: RDEPEND cat/a This is solvable. If package managers can't solve this, they can't install Gnome off a stage 3... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On 05:54 Sat 19 Apr , Ciaran McCreesh wrote: > On Fri, 18 Apr 2008 21:45:13 -0700 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > I'd go with RDEPEND only. Any other interpretation results in > > installing build-time-only packages along with a binpkg, which > > doesn't seem to make sense. > > That's definitely not what we want. Only a package's DEPENDs have to be > installed and usable when that package is built. Its RDEPENDs don't > have to be installed until that package is treated as usable. I previously failed to clarify the situation I preferred because either 1 or 2b qualify as requiring RDEPEND to be installed. My interpretation is pkg_* counts as runtime (I can imagine a package wanting to run itself at this point), so packages in RDEPEND should be usable at that point. Really, it seems to be an additional type of dependency that neither DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't quite capturing it either. I say this because I wouldn't want everything in DEPEND installed with a binpkg so it can run pkg_*, and I also can see how some people wouldn't consider a package in a runnable state until pkg_* have finished (so thus RDEPEND shouldn't be required). > For why this matters: > > cat/a-1: RDEPEND cat/b > cat/b-1: RDEPEND cat/a > > This is solvable. If package managers can't solve this, they can't > install Gnome off a stage 3... Dealing with this under my interpretation is a bit weird. I think it might need some sort of staging area. That's one reason I mentioned the additional dep type. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Fri, 18 Apr 2008 22:27:21 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > My interpretation is pkg_* counts as runtime (I can imagine a package > wanting to run itself at this point), so packages in RDEPEND should > be usable at that point. Which would be fine, except it makes the tree unusable. > Really, it seems to be an additional type of dependency that neither > DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't > quite capturing it either. Yup, and for future EAPIs labels can fix this. But we have to have a sound solution for current EAPIs. -- Ciaran McCreesh signature.asc Description: PGP signature
