Gentoo Ebuilds?

[fryfrog]

I grabbed the two gentoo ebuilds and got them working. I was wondering what the plan was for how they would be setup or how they should be setup.

I ended up putting the showeq ebuild in /usr/local/portage/game-utils/showeq and the showeq-maps ebuild in /usr/local/portage/game-utils/showeq-maps. Originally I tried putting maps in /showeq, but ebuild <package> digest would not run. I believe it pulls the expected path from the name of the ebuild.

At this point, I was able to see both in emerge BUT showeq did not depend on showeq-maps. I edited the ebuild and altered the depend line to read "game-utils/showeq-maps" instead of "virtual/seq-maps". This made showeq depend on showeq-maps.

Is showeq-maps meant to be somewhere else?

[Zaphod]

well, I've submitted them to Gentoo to be included under games-util/showeq and games-util/showeq-maps.

As far as dependencies are concerned, I personally don't view them as a dependency since ShowEQ can run without them, and you can get and use maps from other sources. Plus the maps can technically be used with other tools. Im still working out how I'll want things in the end. Plus, running 'emerge showeq showeq-maps' isn't that difficult, is it?

I'm just thrilled I got them to work. Now we'll just have to see if Gentoo accepts them. It'll make life easier for my fellow Gentoo users.

Enjoy,
Zaphod (dohpaZ)

[fryfrog]

Ah, I see. It does make perfect sense now that its /showeq and /showeq-maps. What threw me off was the commented out entry for "virtual/seq-maps".

While its true that showeq will work with out the maps, they are an important part of it. The question is, do you make a new USE variable (I don't know how the gentoo devs feel about this) or do you just make showeq depend on the maps?

I personally would lean tward including showeq-maps as a dependancy of showeq rather than in USE or simply not including it at all. It just makes more sense to me.

As a test though, I wanted to see what would happen if showeq was emerged with showeq-maps as a dependancy AND a new release of showeq-maps was done.

"emerge -u world -pv" does NOT catch the update (because showeq-maps is not recorded in the world file) but "emerge -uD world -pv" does catch it.

Unfortunatly, I'm not quite sure how to turn it into a USE variable and test that way.

If you are going for a more unified, easy to install approach... would it maybe be good to copy what other package maintainers do? Do the debian and slackware packages make showeq depend on showeq-maps?

[Zaphod]

Slackware doesn't support dependencies.
Debian packages were apparently setup using 'recommends showeq-maps | mapfiend-maps' which are virtual packages (so you can install only one of them).

As far as I've seen Gentoo doesn't support a recommends system. DEPEND and RDEPEND yes, but not a recommends. I tried playing with the virtual stuff but it didn't work as I expected and seems to require harder to acquire approvals then a package specific USE from what I've been reading in the docs and seeing in the ebuilds from other projects.

Please note, that I'm still learning the Gentoo ebuild stuff, and that some of their documentation seems to be out of date and contradicts other documentation of theirs.


Enjoy,
Zaphod (dohpaZ)

[fryfrog]

I've been playing around with ebuilds also, though not quite as good as the showeq ones :)

I modified the ivtv ebuild for ivtv ck's version.

Anyway, after thinking about it and playing with your ebuilds, I think the best solution is to simply have "showeq" and "showeq-maps", w/o any dependencies. You are right, in its basest form... showeq doesn't actually REQUIRE the maps. It just helps to have em, and in theory... you could use other maps right?

Also, by having them emerge them seperatly they get recorded into the world file and will actually get updated when an update is released.

[fryfrog]

I think I found a good way of dealing with it, I am just now looking into a way of ONLY outputting it if showeq-maps is NOT emerged already.


einfo "ShowEQ will work without the game-utils/showeq-maps package, but"
einfo "it is strongly suggested you emerge showeq-maps for full functionality."

[monklett]

Given that the going-forward plan is to decouple maps from the main tree, and that they update only rarely (with each new expansion, usually), having them as an optional add-on package seems like a logical way to go. Conceivably, a user could be interested in other features of ShowEQ than the maps anyway, such as spell timers, exp display, etc.

I like just leaving it the way it is, with the disclaimer at the end; a hard-coded dependency seems unnecessary.

BTW, are filter files going to be bundled with the maps, the main distro, or continue on in the current 'sold separately' fashion? Cause ideally, this would seem to be something that would go in with the maps ebuild; in most cases, filters would only change with the maps, and they probably wouldn't be very useful separately. I also vaguely recall a stand-alone map format conversion perl script; maybe those kinds of goodies would also be things to add to the maps ebuild.

[elf]

Adding the maps as a dependency seems unneeded. I think it would be easier to download the maps once as a emerge and then update them, manually and individually, as needed rather then having the temptation to let emerge download them all when just one cave/wall/area has been added.

Vice versa, should the maps depend on the main project?

[domesticbeer]

Hmm anyone know the status on showeq 5.x getting into portage, I am just seeing 4.x version in my portage tree.