[arch-dev-public] [RFC] New package: vte3-2.90
(I would really like opinions from our GNOME maintainers on this.) Seeing as vte3 0.38.0 in [testing] has a new API, I went ahead a created a todo list to rebuild the packages that depend on the old libvte2_90 library. [1] Patches that port the affected software to the new API might not be available at the moment and it could be a while until upstream developers add support for vte-2.91 (see [2] for an example). To solve this I suggest we keep the old library around for some time to allow software to be ported to the new API. The actions taken would be to: 1) Repackage the old library as vte3-2.90 (or vte-2.90, not sure about the name) 2) Move etc/profile.d/vte.sh from vte3 to vte-common to fix the file conflict (Example PKGBUILD is attached.) [1] https://www.archlinux.org/todo/vte3-0380/ [2] https://bugs.launchpad.net/sakura/+bug/1337962
Hi On Sun, Sep 28, 2014 at 1:26 PM, Evangelos Foutras <evangelos@foutrelis.com> wrote:
(I would really like opinions from our GNOME maintainers on this.)
Seeing as vte3 0.38.0 in [testing] has a new API, I went ahead a created a todo list to rebuild the packages that depend on the old libvte2_90 library. [1]
Patches that port the affected software to the new API might not be available at the moment and it could be a while until upstream developers add support for vte-2.91 (see [2] for an example).
To solve this I suggest we keep the old library around for some time to allow software to be ported to the new API.
The actions taken would be to:
1) Repackage the old library as vte3-2.90 (or vte-2.90, not sure about the name)
This is the best thing we can do now. I briefly looked at vte 0.38 and found that it contains *a lot* of API changes. It requires non-trivial patches to port sakura and other applications. Let's leave the task of API porting to the apps developers. I also suggest to create upstream bugs to track the migration.
2) Move etc/profile.d/vte.sh from vte3 to vte-common to fix the file conflict
Are you going to remove vte-common once the migration is done?
(Example PKGBUILD is attached.)
[1] https://www.archlinux.org/todo/vte3-0380/ [2] https://bugs.launchpad.net/sakura/+bug/1337962
On 29 September 2014 06:45, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
Are you going to remove vte-common once the migration is done?
No, it's an existing package which currently only contains usr/lib/vte/gnome-pty-helper which is split off from the vte3 package. We would just also add etc/profile.d/vte.sh to it and I believe this change doesn't have to be reverted in the future.
On Mon, Sep 29, 2014 at 5:45 AM, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
This is the best thing we can do now. I briefly looked at vte 0.38 and found that it contains *a lot* of API changes. It requires non-trivial patches to port sakura and other applications. Let's leave the task of API porting to the apps developers.
Well, at least in the apps I ported the API changes weren't that difficult to adapt to. But, they weren't dedicated terminal applications. IIRC features were removed where the best we could do would be stubbing them out. On another note, I wouldn't be opposed to using this opportunity to flip our package names around, so we'll have vte2, vte2.90 and vte. Or, if we want to match the library names, vte, vte2_90 and vte-2.91. Or maybe some other combination. In any case, vte3 isn't really the right name.
On 2014-09-29 08:35, Jan Alexander Steffens wrote:
On Mon, Sep 29, 2014 at 5:45 AM, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
This is the best thing we can do now. I briefly looked at vte 0.38 and found that it contains *a lot* of API changes. It requires non-trivial patches to port sakura and other applications. Let's leave the task of API porting to the apps developers.
Well, at least in the apps I ported the API changes weren't that difficult to adapt to. But, they weren't dedicated terminal applications. IIRC features were removed where the best we could do would be stubbing them out.
On another note, I wouldn't be opposed to using this opportunity to flip our package names around, so we'll have vte2, vte2.90 and vte. Or, if we want to match the library names, vte, vte2_90 and vte-2.91. Or maybe some other combination. In any case, vte3 isn't really the right name.
Note that the whole reason for vte-common (the pty helper binary) is not an issue anymore with latest vte3 anymore. Upstream has deprecated it and disabled the build by default, I enabled it for now, but when we disable it again, the binary can move to the vte2 package. I'm not very happy with having 2 outdated copies of vte in our repos though, it's another old library that will not receive any maintenance at all. I only want to package the older version in our repos if someone can assure me that it will stay active for only 6 months, after that it should disappear from repos and all applications that haven't been ported should die together with it.
On Mon, Sep 29, 2014 at 6:39 PM, <jan@jgc.homeip.net> wrote:
On 2014-09-29 08:35, Jan Alexander Steffens wrote:
On Mon, Sep 29, 2014 at 5:45 AM, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
This is the best thing we can do now. I briefly looked at vte 0.38 and found that it contains *a lot* of API changes. It requires non-trivial patches to port sakura and other applications. Let's leave the task of API porting to the apps developers.
Well, at least in the apps I ported the API changes weren't that difficult to adapt to. But, they weren't dedicated terminal applications. IIRC features were removed where the best we could do would be stubbing them out.
On another note, I wouldn't be opposed to using this opportunity to flip our package names around, so we'll have vte2, vte2.90 and vte. Or, if we want to match the library names, vte, vte2_90 and vte-2.91. Or maybe some other combination. In any case, vte3 isn't really the right name.
Note that the whole reason for vte-common (the pty helper binary) is not an issue anymore with latest vte3 anymore. Upstream has deprecated it and disabled the build by default, I enabled it for now, but when we disable it again, the binary can move to the vte2 package.
I'm not very happy with having 2 outdated copies of vte in our repos though, it's another old library that will not receive any maintenance at all. I only want to package the older version in our repos if someone can assure me that it will stay active for only 6 months, after that it should disappear from repos and all applications that haven't been ported should die together with it.
The terminal plugin for Cairo Dock is now fully ported with the help of Anatol. I had a look at pantheon-terminal as well, but it's way out of my league. Changes are not straightforward for someone who does not speak Vala or C: some functions are deprecated and/or no longer available, and it's not just VTE :( I opened a bug report on Launchpad and am waiting for some feedback, but keeping the old one around for a little while would be nice.
Hi
The terminal plugin for Cairo Dock is now fully ported with the help of Anatol. I had a look at pantheon-terminal as well, but it's way out of my league. Changes are not straightforward for someone who does not speak Vala or C: some functions are deprecated and/or no longer available, and it's not just VTE :( I opened a bug report on Launchpad and am waiting for some feedback, but keeping the old one around for a little while would be nice.
For the record here is the pantheon-terminal ticket https://bugs.launchpad.net/pantheon-terminal/+bug/1375346 I suspect that amount of changes for pantheon-terminal will be comparable to sakura.
On 29/09/14 19:39, jan@jgc.homeip.net wrote:
I'm not very happy with having 2 outdated copies of vte in our repos though, it's another old library that will not receive any maintenance at all. I only want to package the older version in our repos if someone can assure me that it will stay active for only 6 months, after that it should disappear from repos and all applications that haven't been ported should die together with it.
So as not to delay the Gnome 3.14 move even longer, I went ahead and added vte290 to [testing] and rebuilt roxterm, sakura and tilda against that in [community-testing]. I also moved etc/profile.d/vte.sh into vte-common 0.38.0-2. I hope you are OK with the above changes; of course, once these three terminal emulators add support for vte-2.91, we can go ahead and drop vte290. When you do move Gnome 3.14 to the stable repos, please also move vte290 to [extra] and the following packages to [community]: cairo-dock cairo-dock-plugins giggle nemiver pantheon-terminal remmina roxterm sakura tilda
participants (5)
-
Anatol Pomozov
-
Evangelos Foutras
-
Jan Alexander Steffens
-
jan＠jgc.homeip.net
-
Maxime Gauduin