Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 394403 - media-gfx/iscan-plugin-gt-x820 ebuild request
Summary: media-gfx/iscan-plugin-gt-x820 ebuild request
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Diego Elio Pettenò (RETIRED)
URL: http://www.avasys.jp/lx-bin2/linux_e/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-12 01:38 UTC by coran.fisher@gmail.com
Modified: 2017-04-04 01:32 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
iscan-plugin-gt-x820-2.1.2.1.ebuild (iscan-plugin-gt-x820-2.1.2.1.ebuild,1.76 KB, text/plain)
2011-12-12 01:39 UTC, coran.fisher@gmail.com
Details
media-gfx/iscan-plugin-gt-x820-2.1.2.1.ebuild (iscan-plugin-gt-x820-2.1.2.1.ebuild,2.34 KB, text/plain)
2012-08-24 04:15 UTC, Jared B.
Details

Note You need to log in before you can comment on or make changes to this bug.
Description coran.fisher@gmail.com 2011-12-12 01:38:21 UTC
It is suggested for my scanner


Reproducible: Always
Comment 1 coran.fisher@gmail.com 2011-12-12 01:39:39 UTC
Created attachment 295509 [details]
iscan-plugin-gt-x820-2.1.2.1.ebuild

This is just a renamed media-gfx/iscan-plugin-gt-x770-2.1.2.1-r1
ebuild.
Comment 2 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-07-05 19:01:58 UTC
Coran, Jared, can you update it to be more similar to the gt-x770 ebuild now in tree (which is the one I just committed)?

Jared are you still game to proxy-maintain it? Coran? Basically I'd need you two to test the new versions when they come out and prod me to update them (if needed with extra changes involved, see the recent change to gt-s80 to support the s55/s85).

If one of you, or both of you, would like to do that, I can commit the updated ebuild in portage right away.
Comment 3 Jared B. 2012-07-05 19:46:00 UTC
Yeah, I'd be happy to help.  That'd be one less out-of-tree ebuild I have to worry about.  If you don't mind, though, give me until tonight so I can check out the current ebuild and compare it against the local one I'm using at home.  Want to at first take a look at what I'll be dealing with before committing to it.  :-)
Comment 4 Jared B. 2012-07-06 08:30:36 UTC
I'm having trouble getting this version working for me and I ran out of time trying to troubleshoot.  Let me try to mess with this some more tomorrow night and I'll get back to you.
Comment 5 Jared B. 2012-07-07 05:07:01 UTC
Sorry guys, but I won't be able to work on this for another few days.  This came up at an exceptionally bad time for me, and I just haven't had any time to spend on it.  Will be back at my computer again next week, though, and I'll try to jump back on this.
Comment 6 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-07-08 19:54:47 UTC
Jared there's no hurry on my side, don't worry.
Comment 7 Jared B. 2012-08-13 06:04:29 UTC
Sorry for the long delay - as I mentioned, was really busy when this came up previously.  Things are finally calming down again...

Diego, can you tell me what these lines are supposed to do?

in pkg_postinst():
	[[ -n ${REPLACING_VERSIONS} ]] && return

in pkg_prerm():
	[[ -n ${REPLACED_BY_VERSION} ]] && return

I had trouble getting the plugin properly registered, and it turned out to be (mostly) related to that line in pkg_postinst().  With it in place, the driver will be registered (and thus work) on clean installs, but NOT when upgrading from the existing 2.1.2 driver.  However, if I comment out that line, the driver will be registered during both fresh installs AND upgrades, which seems like it would be the desired behavior.

Perhaps I'm missing something, though.  What are you trying to accomplish (or prevent) with that condition?

Since I was constantly bouncing back and forth between the old and new driver for testing, it took a while for me to realize that the issue with with the upgrade and not a problem with the iscan-registry command itself.

Anyway, let me know what you think, please.  If we can remove that condition, then I have an ebuild that's working and ready to go.  Otherwise, I'll need to get a better understanding of what's going on there so I can tweak it appropriately.

Thanks.
Comment 8 Jared B. 2012-08-22 05:00:48 UTC
ping.  Diego - did you see my last update?
Comment 9 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-08-22 05:55:45 UTC
Ehm yes and no, I saw it and was supposed to reply to it but then I forgot, sorry :( Good thing you pinged.

It should work on both install _and_ upgrade by not trying to de-register when upgrading. It might not behave correctly if you got a previous version not based on my ebuild though.

In that case if you don't mind giving a try to the situation, add this to the DEPEND and RDEPEND:

!!<media-gfx/iscan-plugin-gt-x820-{current-version}

this way it should first uninstall (and possibly de-register) the current package, then do a ("clean") merge.

To test whether it works:

 - install the original ebuild you had;
 - upgrade to the ebuild with that blocker in place.

It should get registered at that point. If it doesn't let me know and I'll check again the logic to make sure it's not broken.
Comment 10 Jared B. 2012-08-24 03:31:19 UTC
Thanks for the feedback.  That worked, but with an ugly side effect:  the blocker caused a hard block in portage, and I had to manually uninstall the old version first.  That's not exactly a showstopper, but it is pretty inconvenient.

I've seen portgae handle blockers like this in other packages by automatically removing the old version, but I couldn't figure out how to make that work here.  Is there any trick to that?  or does it just not apply here for some reason?
Comment 11 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-08-24 03:36:15 UTC
Can you post the full ebuild you're using? Zac might know better, I was under the assumption it would have worked out of the box as well.
Comment 12 Jared B. 2012-08-24 04:15:22 UTC
Created attachment 322056 [details]
media-gfx/iscan-plugin-gt-x820-2.1.2.1.ebuild

posting ebuild as requested.  In case it matters, I'm running the stable version of portage.  I know this version can handle automatic uninstalls in at least certain situations, but perhaps unstable is needed for all the magic to happen?
Comment 13 Zac Medico gentoo-dev 2012-08-24 04:35:14 UTC
You used a hard !!blocker instead of a soft !blocker, and portage doesn't solve hard blockers automatically yet (bug #250286).
Comment 14 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-08-24 04:44:38 UTC
Okay that's my fault then :/
Comment 15 Jared B. 2012-08-26 03:48:50 UTC
Well, I had actually tried using only a single !, but when I do that it doesn't force the uninstall, and the upgrade results in the same situation I mentioned originally: the new firmware is not registered.  So:

* with no blocker, the firmware is not registered
* with ! blocker, the firmware is not registered
* with !! blocker, the firmware IS registered, but the upgrade requires manually uninstalling the old version

So, I guess the last option would be best, since even though it requires manually intervention, it's the only option that results in a working scanner.  Not crazy about the manual intervention, though, but then again, I don't think this is even in the portage tree yet, so it won't affect all that many people.

Diego, what do you think?  Should we just go with thet last ebuild I attached as-is?  or do you have any other suggestions?
Comment 16 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-08-26 19:43:14 UTC
Sounds good to me — I'll commit the ebuild today.