| Summary: | Evolution 1.4_rc1 ebuilds | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Matthew Schick <matt> |
| Component: | New packages | Assignee: | Alastair Tse (RETIRED) <liquidx> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | Keywords: | EBUILD |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://developer.ximian.com/projects/evolution/release_notes/1.3.92.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Tarball with all needed evo ebuilds | ||
|
Description
Matthew Schick
2003-05-27 14:33:01 UTC
Created attachment 12467 [details]
Tarball with all needed evo ebuilds
thanks but i already know about the release and have ebuilds for them, but they're (current ones in portage) just not good enough for me to bump blindly into portage . for example: 1. do you know why they can't live side by side? or is it just because it says so in the release? i'm running them side by side without any problem. 2. there is still the big HACK warning in libgtkhtml which has now spread the problem to libgal as well. you haven't to found any clean way around it either, afaik. did you upgrade from libgtkhtml-3.0.3 and gal-1.99.4? because if you did, you'd notice the linking problems unless you unmerged them before upgrading. btw, for the evolution blocking prob in your ebuild, this line is wrong: !net-mail/evolution-1.3* i'll leave it as an exercise for you to figure out why. I kinda figured there was someone out there working on this one already, just figured I'd try to give a hand... I don't know of any reason this one can't be installed other than the announcement. I don't generally question big bold warnings like that. The linking problem does still seem to be there for some folks, tho I didn't run into it myself. As for the blocking... I tried using: !=net-mail/evolution-1.3* !net-mail/evolution-1.3.3 !evolution-1.3* and several other combinations, but still nothing. Maybe instead of a smartass reply you could show me what works here. well, i was just telling you that the line was wrong syntacically so you can see. since you're insistant on me tutoring you: 1. you cannot block the same package you are upgrading. 2. you if it really is replacing evo1, then why not put it back into SLOT="1" or whatever evo1's slot is. 3. whenever you append a version number, it must be prefixed by > = or <. i don't know why you would want to block all 1.3* ? it says it cannot be installed in parallel meaning it would overwrite 1.2. this isn't an important point anyway, so i'm not going to be a "smartass" and argue about it here. First of all, I do NOT appreciate your patronizing tone here. I've seen you and Foser whining about there being too many bugs/packages to handle countless times both on the forums and here on bugzilla, yet slamming people left and right for trying to help. I'll finish saying my piece here and I'm done. 1 & 2. Take a look at the ebuild. It's slotted 0 just like the 1.2 series. Now it would seem to me that you should be able to block a package that is in a different slot since technically you are only upgrading within the slot. My guess is that this isn't the case, hence the block not working. 3. Read my last comment. It's pretty obvious why you would want to block the 1.3* versions, but "i'll leave it as an exercise for you to figure out why." One last thing from the ebuild man page:
Extended Atom Prefixes [!] and Postfixes [*]
Now to get even fancier, we provide the ability
to define blocking packages and version range
matching. Also note that these extended pre-
fixes/postfixes may be combined in any way with
the atom classes defined above. Here are some
common examples you may find in the portage tree:
!app-text/dos2unix
=dev-libs/glib-2*
!net-fs/samba-2*
! means block packages from being installed at
the same time. * means match any version of the
package so long as the specified base is matched.
So with a version of '2*', we can match '2.1',
'2.2', '2.2.1', etc... and not match version
'1.0', '3.0', '4.1', etc...
ok .. if you really insist on arguing with this: mcvaio portage # etcat depends "\![<=>]" [ Results for search key : \![<=>] ] * x11-libs/qt-3.1.2-r1 !=kde-base/kdelibs-3.1 * x11-libs/qt-3.1.2-r2 !=kde-base/kdelibs-3.1 * x11-libs/qt-3.1.2-r3 !=kde-base/kdelibs-3.1 * x11-libs/qt-3.1.2 !=kde-base/kdelibs-3.1 * x11-libs/xft-2.0.1-r2 !>=x11-base/xfree-4.3-r2 * dev-util/subversion-0.21.0-r1 !>=apache-2* * dev-util/subversion-0.21.0 !>=apache-2* * dev-util/subversion-0.22.2 !>=apache-2* * gnome-extra/fontilus-0.1 !<gnome-base/gnome-2.0.3-r1 * gnome-extra/fontilus-0.3 !<gnome-base/gnome-2.0.3-r1 * gnome-extra/fontilus-0.4 !<gnome-base/gnome-2.0.3-r1 my understanding is that you need to use a comparison operator if you include a version. if you don't then you don't need one, like !virtual/xft. matt, i don't understand why you were getting worked up about such a trivial thing. i try to be diplomatic for most times, but it just doesn't work with you. i'm not going to continue this argument with you any longer, i'd rather spend that time doing REAL WORLD WORK or actually fixing bugs like libgtkhtml problems. "i'll leave it as an exercise for you to figure out why." -- Alastair That line right there shows hostility and that is why this has become what it is. If you couldn't figure that one out, then there is no hope for you. please don't turn this into a slanging match. if you want to abuse or insult me, please do it via email. bugzilla is not the right place for this. well, 1.3.92 is in portage. i didn't name it 1.4_rc1 because it seems like that is their marketing name rather than the real version number. any how, 1.4 will be out in a weeks time anyway. also, my version keeps on slotting it in "2" (in hindsight that was a bad number, i should of used "1.4") but removing the /usr/bin/evolution symlink. i've been using both 1.2 and 1.3 for a while now and i haven't come across any problems. so i have to say that it seems more like a marketing and packaging move rather than a technical limitation that it stops 1.2 from working. and as for the problems with libgtkhtml and gal, i still haven't found a solution for that yet. so right now the hacks continue to remain. Cool! I've gone ahead and pulled my ebuilds from the site so we don't conflict... Any chance of getting rid of my lovely comments above? :( i don't think its possible to remove comments from bugzilla, at least i don't have the perms to do that. |
