| |||||||||||||
Quotes of the weekQuotes of the weekPosted Feb 8, 2013 17:38 UTC (Fri) by dlang (✭ supporter ✭, #313)In reply to: Quotes of the week by mpr22 Parent article: Quotes of the week
I've been bit by this a few times, it's very annoying to have an app that you can download a tarball for and compile it, but not check out of git and compile it (because configure is a generated file and therefor not stored in git)
(Log in to post comments)
Quotes of the week Posted Feb 8, 2013 18:05 UTC (Fri) by raven667 (subscriber, #5198) [Link]
Maybe there should just be recognition that the source tree and tarball/package may be two (similar) but distinct things, one is for editing and the other is an installable artifact.
Quotes of the week Posted Feb 11, 2013 11:03 UTC (Mon) by epa (subscriber, #39769) [Link] Maybe there should just be recognition that the source tree and tarball/package may be two (similar) but distinct things, one is for editing and the other is an installable artifact.This makes a lot of sense. The issue is who is responsible for generating the tarball from the source tree? If it is the upstream developer, then we have situations like the one that prompted this 'quote of the week', where upstreams have to be prodded to rerun autoconf to add support for a new processor. It might be better for upstream to concentrate on developing the software and blessing particular versions as 'releases' (probably using tags in the version control system), while those who are interested in packaging and installing it can generate the tarball or package from the upstream source.
Quotes of the week Posted Feb 11, 2013 14:58 UTC (Mon) by raven667 (subscriber, #5198) [Link]
I still think that you want the upstream making release tarballs but a concerned packager can still download the source and make their own release using updated autoconf tools if necessary. There might even be something to contribute back to the main developers, like an RPM spec file or other packaging info
|
|||||||||||||