[ptxdist] patchlevel version numbers....

[ptxdist] patchlevel version numbers....

[David Jander]

Hi all,

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?

Best regards,

-- 
David Jander
Protonic Holland.

-- 
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] patchlevel version numbers....

[Robert Schwebel]

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

Re: [ptxdist] patchlevel version numbers....

[David Jander]

On Fri, 8 Jun 2012 09:08:03 +0200
Robert Schwebel <r.schwebel@pengutronix.de> wrote:

> 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.

I agree, that most of the time, one would prefer a simple firmware "blob".
But there are a few reasons for being able to upgrade individual packages.
For example, if there are a few different variants that need the same base OS,
but different packages on top. Or when people can purchase extra
software options.

Take for example Dream-Multimedia's Dreambox sat receivers. Those are
currently OE-based, and use .ipk packages via opkg's package feeds.
Of course this is an extreme case ;-)

> 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.

Thanks for the invitation. In the case of tslib, I am experimenting with this
kind of approach:

--- /usr/local/lib/ptxdist-2011.12.0/rules/tslib.make   2011-11-23 16:33:53.000000000 +0100
+++ rules/tslib.make    2012-06-08 15:51:41.000000000 +0200
@@ -17,13 +17,16 @@
 #
 # Paths and names
 #
-TSLIB_VERSION  := 1.0
-TSLIB_MD5      := 970cc089da1a75f6626172543a2e8df4
-TSLIB          := tslib-$(TSLIB_VERSION)
-TSLIB_SUFFIX   := tar.bz2
-TSLIB_URL      := http://www.pengutronix.de/software/ptxdist/temporary-src/$(TSLIB).$(TSLIB_SUFFIX)
-TSLIB_SOURCE   := $(SRCDIR)/$(TSLIB).$(TSLIB_SUFFIX)
-TSLIB_DIR      := $(BUILDDIR)/$(TSLIB)
+TSLIB_UPSTREAM_VERSION := 1.0
+TSLIB_PATCHLEVEL       := 2
+TSLIB_VERSION          := $(TSLIB_UPSTREAM_VERSION)-$(TSLIB_PATCHLEVEL)
+TSLIB_MD5              := 970cc089da1a75f6626172543a2e8df4
+TSLIB_UPSTREAM         := tslib-$(TSLIB_UPSTREAM_VERSION)
+TSLIB                  := tslib-$(TSLIB_VERSION)
+TSLIB_SUFFIX           := tar.bz2
+TSLIB_URL              := http://www.pengutronix.de/software/ptxdist/temporary-src/$(TSLIB_UPSTREAM).$(TSLIB_SUFFIX)
+TSLIB_SOURCE           := $(SRCDIR)/$(TSLIB_UPSTREAM).$(TSLIB_SUFFIX)
+TSLIB_DIR              := $(BUILDDIR)/$(TSLIB)
 
 # ----------------------------------------------------------------------------
 # Get


It seems to work. Of course, the details of it could better be hidden in the
core macros of ptxdist, instead of every make file.

Best regards,

-- 
David Jander
Protonic Holland.

-- 
ptxdist mailing list
ptxdist@pengutronix.de