From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from dude.hi.pengutronix.de ([2001:6f8:1178:2:21e:67ff:fe11:9c5c]) by metis.ext.pengutronix.de with esmtp (Exim 4.72) (envelope-from ) id 1SctIh-0002er-7S for ptxdist@pengutronix.de; Fri, 08 Jun 2012 09:08:03 +0200 Received: from rsc by dude.hi.pengutronix.de with local (Exim 4.77) (envelope-from ) id 1SctIh-0000uX-6O for ptxdist@pengutronix.de; Fri, 08 Jun 2012 09:08:03 +0200 Date: Fri, 8 Jun 2012 09:08:03 +0200 From: Robert Schwebel Message-ID: <20120608070803.GA30137@pengutronix.de> References: <20120607153321.2572ccf8@archvile> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120607153321.2572ccf8@archvile> Subject: Re: [ptxdist] patchlevel version numbers.... Reply-To: ptxdist@pengutronix.de List-Id: PTXdist Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ptxdist-bounces@pengutronix.de Errors-To: ptxdist-bounces@pengutronix.de To: ptxdist@pengutronix.de On Thu, Jun 07, 2012 at 03:33:21PM +0200, David Jander wrote: > My excuses if this had been asked before. I have not found any > information about this issue: > > Currently version numbers in ptxdist (version 2011.12) are tightly > coupled to the original source filename that is downloaded. This is in > the end the version number in the package filename. But, what if there > are local patches to the package (bug fixes, cross-compile fixes, > etc...), shouldn't the package get a suffix to the version number > (i.e. like debian package version numbers)? > > Now I have the situation that we have added extra patches to fix bugs > in packages that were previously released to customers. I can't find a > way to properly differentiate the new package from the old one. How is > this supposed to be dealt with? I think we don't have a really good strategy for that yet; for most industrial users, using packages is more development feature, because people often treat the "firmware" as a big blob with one version number. That obviously has the advantage that less package combinations need to be tested for deployment, but of course it is far from being optimal. We definitely want to have a strategy for people who want to maintain their own distribution. Next week at the Pengutronix TechWeek 2012, "updating" / "packaging" etc is one of the focus topics of the platform team. We'd like to identify the issues for software updating (I think there are about 4 major usecases) and come up with possible solutions. So if you have ideas how to improve the mechanisms, we are very open to suggestions. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- ptxdist mailing list ptxdist@pengutronix.de