On Fri, 17 Apr 2015 02:47:06 -0500 Rob Landley <[email protected]> wrote:
>On Wed, Apr 15, 2015 at 12:51 PM, enh <[email protected]> wrote: >> in ad602aa127e44eade76fbb05fd27ee8f5825282a you added a --version >> that outputs a constant string defined in main.c. i just wanted to >> point out that -- for the foreseeable future until toybox is "mostly >> done" -- this means Android will pretty much always lie. we'll be >> some random SHA ahead of that version. (right now, for example, >> we're far ahead of 0.5.2 but will claim to be 0.5.2.) > >Yup. I don't really have a good answer to that. > >I suppose I can add plumbing that _if_ it's built from git (release >tarballs aren't) then use the git describe --tags output, otherwise >fall back to the VERSION file? Hmmm... Mostly. Maybe the notion of version as a major/minor/patch designation is really a legacy construct/tradition from other versioning systems of yore... Now that there is a more precise method, e.g. the hash, maybe that should be the only expression of 'version'. It's hard for a human to tell the order of the versions with just a hash though. Yet tag can be anything, not just an emulated maj/min/patch designator. e.g. --version 0.5.2-g0bfbb64 OR release-codename-g0bfbb64 So, each human-understanding-optimized version (release) name is the tag, with the exact version the hash (as you mention above using 'describe'), but always use it - not just on git builds. Generating the tarball creates the VERSION file in the tarball using git describe --tags. A build looks for the VERSION file first, then falls back to git describe --tags. VERSION is never in the git tree. -C > >> you mention in the checkin comment that you don't trust yourself to >> keep things up to date --- did you consider setting it in the >> makefile instead and grepping the version out of the www/ directory? > >Yes, and I'm even less likely to remember to update it there. > >> or, if you plan on having an rpm spec file or equivalent, from there? > >I'm all for people packaging toybox in RPM. And in .deb. And in gentoo >ebuilds for portage. And in pacman for arch. And in bitbake for >openembedded and yocto and tizen. And in slack packages. And in >buildroot. And maybe android apk works in there somehow, or ipkg or >opkg. And apparently sabotage is creating one called "butch"... > >Am I having toybox depend on any of that? Nope. > >> _i_ don't care, but if people report toybox-on-Android bugs to you >> rather than to me, you might have a confusing time with the current >> setup. > >Good point. > >Try now? > >> even if you surrounded the #define with #ifndef, i'm not sure what >> i'd set it to in the makefile. version numbers don't really make much >> sense until you're old and stable. we still have trouble with strace >> because although they're old they're still very much under active >> development, and often in areas we need (such as aarch64 support) or >> want (like the recent ioctl disambiguation improvements). so strace >> --version is always a lie on Android too. (but strace doesn't ship as >> part of the system image, so only a developer would ever notice and >> hopefully they'd be looking at git log anyway.) > >I have static strace binaries at http://landley.net/aboriginal/bin for >various architectures but I hadn't hugely noticed the need for regular >version updates on them? (Modulo that time powerpc system calls >changed...) > >> probably not going to be a problem -- i pretty much always have to >> ask "what version of Android?" on any bug report anyway -- but i >> thought i'd mention it. > >As long as I've added --version I might as well do it _right_, it's >good to raise issues so I finish fixing the problem. > >Rob >_______________________________________________ >Toybox mailing list >[email protected] >http://lists.landley.net/listinfo.cgi/toybox-landley.net -- Regards, Christopher Barry Random geeky fortune: Do not apply to broken skin. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
