On Saturday, July 07, 2012 22:22:38 Michael Jansen wrote: > On Saturday, July 07, 2012 04:04:42 PM Michael Pyne wrote: > > On Saturday, July 07, 2012 18:27:42 Jorge Manuel B. S. Vicetto wrote: > > > >>> I think we did it for a time. At least i remember some " a new > > > >>> snow storm, a new snapshot" commits by dirk. But no idea how > > > >>> they got released/packaged. > > > >> > > > >> Yes, you did that in the past and we really disliked it. > > > > > > > > Could you find out how they were named back then for me? Just for > > > > information. > > > > > > > > Mike > > > > > > I can't recall the names used back then, but I'm pretty sure they > > > included the svn id in the names and dir inside the tarball. > > > I tried asking in #gentoo-kde but no one got back to me so I can't > > > help with that. > > > > You can look at ftp://ftp.kde.org/pub/kde/snapshots/ for an example of what > > they used to look like (packagename-svn-$revno.tar.bz2). > > > > This was made easier by later having symlinks available (packagename- > > svn.tar.bz2) (added by myself :P, see svn revision 458465 of kde- > > common/release/dosnapshot) but I can confirm it was a pain in the ass from a > > scripting perspective. > > > > Of course for packagers they wouldn't be using Subversion snapshots but > > plain tarball snapshots, although those suffer the same issues. In fact it > > was worse because the directory name that was extracted to was > > unpredictable (e.g. kdeadmin.tar.bz2 extracts to kdeadmin-1233410/). > > (Sorry for the other empty mail. Wrong button) > > So there is the problem i couldn't see. The directory name it extracts to is considered to be the same as the name of the archive. Just extracted our kdelibs 4.8.3 package and the dir is kdelibs-4.8.3. Build-tool already solves that problem by always using "tar --strip-components=1 --directory=<empty dir named like that module>". That's why i failed to see the problem. > > Is that naming a must?
I think the issue is less about having the version component in the name and more that if there is a version component, that it is easy to piece toward the tagged version. Gentoo already supports betas, RCs, etc. in Portage though they have a different nomenclature (e.g. I think 4.7.0~beta1 would be 4.7.0_beta1 in Portage). But in order to support generic KDE snapshots that nomenclature shouldn't change too much across future releases. As long as it's mostly set one time it shouldn't be hard to generically rewrite KDE versions into what is used by Gentoo (or rather, rewrite the Gentoo version to the KDE version to find the tarball!). All the rest is administrivia in my opinion for a packager (they can rely on a good-enough GNU tar since they can enforce its presence). I would just make sure that the only versioning info in *released* snapshot tarballs and directories is the version itself (i.e. no dates, no revision tags or commit ids). For actual Git snapshots Gentoo uses a separate scheme anyways that even uses git directly, so that shouldn't pose much drama. But I don't think that's what's being discussed here. :) A final note: It sounds like we're going towards only releasing changed packages between updates. I think this is a wonderful idea (as I hate rebuilding a hojillion KDE packages on Gentoo just for a minor point release) but it will be very labor-intensive for packagers if we don't essentially do the work for them by listing out what libraries and applications *individual* versions are present in a given KDE SC, for each release. So there would need to be some kind of automated version extraction (perhaps individual module maintainers could provide this until that's available?) Regards, - Michael Pyne
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
