net-libs/tox-9999 is stuck on an old commit about gentoo-overlay-tox HOT 7 CLOSED

Thing is, you don't want that yet. Basically along with API change protocol was broken, and until all major client will support new API (and thus protocol), newer versions are being held back, due to problems that arise from protocol changes. I'll push ~soon update to overlay that will keep Toxic at commit that still worked with old API. When all major clients will be ported to new API block in ebuilds will be removed, which will probably happen in a ~week (no ETA though).

from gentoo-overlay-tox.

Instead of locking -9999 to a specific commit, why not add another ebuild for that specific commit so -9999 does what it's meant to do?

from gentoo-overlay-tox.

@zamabe hm, this was supposed to be a very temporary measure that should allow most of people ~painless updates (only layman -s tox-overlay && emerge $tox_stuff needed), instead of trying to figure out why -9999 after months of working without any major issue suddenly doesn't work, and in only combination that it could "work" at a time (i.e. newest µTox + newest toxcore, and no, not everything worked even in this combination) it's ~broken when it comes to communicating with other clients on the network, majority of which using still old API.

Thing is, client builds provided by Tox in their repos are all held back on old API to provide for their users as painless experience as possible. For consistency, -9999 ebuilds in Gentoo overlay were locked to commits that at the time correspond to clients working with core on old API.

• clients on new API will cause unnecessary havoc which is not needed (e.g. sending avatars is now done via file transfers, which means that all your contacts will receive "file transfer" from you, which won't really work
• due to changes in message stuff, messages you're sending are cut off by few bytes in beginning, and what you receive from clients on older API has some random(?) stuff in beginning of a message
• using client on newer API you would get constantly spammed with same messages fro client thaat support faux offline messaging due to changes in how confirming message arrival works
• bootstrapping (connecting to network) while most of the network is on old API takes terribly long time

Thing is, it should be as smooth transition as possible for both Gentoo and non-Gentoo Tox users. This hardly would be the case when suddenly not only Gentoo users have problems due to emerging newest µTox on newest core, but also other users with whom they would communicate, who most likely (provided that they don't run Gentoo with same client) also would have worse experience.

This transition was supposed to happen long time ago, and the only "reason" why block isn't gone by now is qTox.

irungentoo gave "deadline" yesterday for qTox to get onto new API, after which builds provided by Tox for µTox and Toxic will be on a new API. So all that is left is to wait either week for deadline, or for qTox to finish transition earlier.

If by knowing all this you still want unlocked stuff now, is there a good reason for it?

Edit: and yes, I know what -9999 usually implicates, but in this case users who would emerge client with new API not only would hinder experience for themselves, but also for other Tox users, out of which overwhelming majority (AFAIK) still uses old API.

from gentoo-overlay-tox.

Yes and no. The thrust of my concern was that locking -9999, even temporarily, means that the ebuild isn't doing its job. The point of locking an ebuild to a commit is philisophically better served by offering a new ebuild which is locked instead of changing the behavior of one which is meant to be guaranteed to be unstable in the name of making it more stable. It is a hostile step to people who do want to build the -9999.

I understand the developments and the majority of users being on a specific API, but it is better to treat the ebuild with the philosophy of the system it belongs in is my thought on this. The point of adding a new ebuild which is frozen at a point in time is to give people access to a specific version of the software, and it seems like that's exactly what you're doing right now, which doesn't fit with a -9999.

Of course, I reserve retraction of my concerns if there are dependencies on the -9999 version instead of on the package, as this is easier than rewriting the deps and life will move on quickly away from this.

from gentoo-overlay-tox.

um, from what I understand, primary job of ebuild is to provide stuff for portage based on which it should be able to emerge things. In process of doing so, it should aim to avoid things that would result in something breaking, and as result emerging failing.

Now, sticking to latest master git for live ebuild would be good if there was something other than -9999 ebuild that people are already using. Since Tox doesn't have any stable version, there could be only made -999 version with hand-picked commits that would allow for something like semi-live ebuild. I was wondering whether to not do it only for transition period between API change, but it would result in situation where suddenly there is -9999 broken, after updating overlay people would get new, shiny -999 which would work for some time, and soon after would be deleted from overlay and→or start to fail too. Breaking people's workflow[1] twice didn't and still doesn't sound like something I would want to do.

Following philosophy is similar to following other set of rules: it's there to make one think really well before breaking rules.

In this case, I think that philosophy hasn't been hurt that much, since ebuild allows people to successfully emerge stuff without breaking their workflow[2].

[1] Instead of just simple layman -s tox-overlay && emerge $tox_stuff, there would be a need to change version from -9999 to -999, and after -999 would start to fail switch back to -9999 EDIT: please note that this steps would require repeating at least twice, i.e. library and at least one client.
[2] In this case one has consistent workflow with earlier experiences, i.e. just layman -s tox-overlay && emerge $tox_stuff

from gentoo-overlay-tox.

You're referring to a version which is, by definition, reserved for things which are almost guaranteed to be unstable as if it is expected to be QA quality (I exaggerate) in your second sentence and thereon :/

Inherent behavior/predictability is broken one way; workflow the other. I don't have much more protest to add or more commentary on the subject since I don't think publishing a misbehaving -9999 is detrimental in this case.

I understand your priority to make the process of interacting with $tox_stuff simpler and less trouble to build ebuilds around, and I appreciate your comparatively voluminous responses to my concern; though I'll remain in disagreement of it being the correct option :p

from gentoo-overlay-tox.

well, a lot of time after it was supposed to happen... a3e18fb

Well, now that master qTox is compatible with new api, block was removed.

from gentoo-overlay-tox.