Hello. On Tue, Sep 08, 2015 at 05:47:13PM +0200, Samuel Thibault wrote: > Cyril Brulebois, le Tue 08 Sep 2015 17:39:24 +0200, a écrit : > > (Adding -boot@ for further discussion.) > > > I'm pondering just building static versions of fdisk,sfdisk,blkid > > > to put in the udebs instead to avoid current and future dependency > > > issues. Would that be acceptable? > > > > > > (That would also mean I can remove lib*-udeb.) > > You could link just libtinfo.a statically.
Another option would probably also be to work out how to get rid of the dependency on libtinfo (for udebs atleast). (There's a configure switch to disable tinfo already, but I guess we want it enabled for regular builds and would like to avoid double builds.) This would probably mean I walk into the same trap again in the future with some other library. Building it completely static is really simple for me and makes sure no (non-udeb or other) dependencies gets picked up in the future and avoids me reintroducing grave bugs. Any issues would be noticed at build-time (eg. if something does not provide a static lib). I'd feel best if I can just forget about udeb existance and building static version of fdisk,sfdisk,blkid seems like it could take away the most common pitfall for me. Are there any issues I should be aware of that would outweigh the benefits mentioned above? (I'm aware it's not perfectly optimal to build staticly, but can anyone forsee any actual practical or policy issue with doing so?) Regards, Andreas Henriksson