Hi Andreas, On Mo 16 Mai 2016 14:37:50 CEST, Andreas Henriksson wrote:
Hello Mike Gabriel. Thanks for looking at packaging a newer freerdp snapshot! I have some questions and doubts below...
Ok. Thanks for bringing up your questions and doubts.
On Sun, May 15, 2016 at 12:53:07AM +0200, Mike Gabriel wrote: [...]* Package name : freerdp2 Version : 2.x (Git snapshot)[...]The new major upstream version (well, upstream is not tagging versions, but we have one upstream dev on the packaging team who recommends Git snapshots) provides new ABI/API. This new source will supercede the currently available Debian source package "freerdp".With new API/ABI a transition is needed (and hopefully upstream properly handles SONAME despite not doing releases), but renaming the source package is not normally how you do a transition.
We have Bernhard Miklautz from FreeRDP upstream on board the Debian freerdp(2) packaging team. With Bernhard we have a considerable impact on upstream bugfixing and issues regarding compliance of the FreeRDP upstream code with FHS, Debian policy, etc.
However, the upstream developers (esp. the main developer) have not cared so much about releases, versions, SONAMEs and such in the past. Since Bernhard has become aware of the needs for some ABI/API reliability regarding the shared FreeRDP library, this has started to improve on the upstream side. However, I think it is still a bit of a journey to get the shared libraries in FreeRDP to a point where other upstream projects can 100% rely on them being ABI/API constant within certain major versions. This is a gut feeling from my side.
One reason for symbols being added / removed from time to time is the customer project driven nature of FreeRDP upstream. Features are added when contracted and mostly always pushed to the master branch directly. Bernhard may correct me if I perceive this wrong or if this has changed recently.
From now on, upstream will support parallel installations of multiple major upstream releases.This bit is quite confusing as you just said upstream doesn't do releases.
The don't do releases. Not yet. They did not have the concept of "major versions" really, before Bernhard pushed the other upstream dev(s) to introduce a major version bump to version 2.x.y and declare everything previous as 1.x.y. (There was a time when there was some 0.7.x and 0.9.x release IIRC, but that is ages ago).
Since I have taken over package maintenance in of freerdp in Debian, I always received Git snapshot recommendations from Bernhard.
So shipping both FreeRDP versions in Debian unstable for a while is possible.Given the lack of followup on existing bug reports do you really think you have the resources to support multiple versions?!
Personally, in the past I did not have enough resources to handle freerdp adequately, you are right. Since Bernhard has jumped on the packaging train, this has changed. He knows about most FreeRDP-internals very well, so we mix his experience with my packaging skills and this improve the situation by far.
Also, I will (very probably) use FreeRDP in one of my upstream projects soon, so then I will have a day-to-day use case for a well maintained FreeRDP in Debian. This is actually the main context for not having orphaned the freerdp package by now.
Please explain a bit more about how you intend to support multiple versions? For example how do you intend to handle the naming of pkg-config files, rename or make the -dev packages conflict?
However, only freerdp2 will be made available in Debian 9.Apparently not and you seem to underestimate the amount of work needed to get something removed from the archive! Are you sure you'll manage to get down to only one version again before the stretch release? How?
Currently, the dependency situation regarding the libfreerdp-client library is quite simple:
Guacomole (guacamole-server) Remmina (remmina) Video Lan Client (vlc) Vinagre (vinagre)So, basically, we need to get these four packages to using the latest libfreerdp(-client|-core) version.
As mentioned renaming the source package is not how you normally do a transtion (only when you want to support multiple versions which you apparently don't want). Please consider handling this like a normal transition.
I have just asked for rejections of my freerdp2 upload to unstable. I have pinged Bernhard Miklautz to reconsider of what to do here.
From my understanding, FreeRDP is a big monolith of code where some portions come in as shared libraries. From what I have seen, you cannot handle FreeRDP's libs like you can do with other shared libraries. This is basically due to upstream not sticking to being ABI/API constant within certain development phases.
Packages depending on FreeRDP shared libraries should start migrating their packages to the new ABI/API for FreeRDP 2.x.Again, please share some information on how you intend to package to make it possible to prepare. Likely you're creating extra work here when not following the normal transition workflow.
Also re-considering this. Most likely, projects building against FreeRDP 1.1 will likely FTBFS when building against 2.0. This probably means that those packages have to move to a new upstream version (or pull in upstream patches that do the ABI bump).
. A transition bug will be file for monitoring this change-over, once the freerdp2 src:package has landed in unstable.An automatic tracker would be available on https://release.debian.org/transitions/ if you followed the normal transition workflow which would be even better.
Considering this.
Looking forward to hearing more details about your plans to be able to prepare for the transition.
I will follow up on this thread (or maybe also Bernhard) once we have discussed the addressed thoughts.
Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de
Attachment:
pgpaxquoqQGyR.pgp
Description: Digitale PGP-Signatur