Shorewall devel - Dec 2007 - Confusing versioning of tarballs and patches for 4.0.6

Hi Tom,

I co-maintain the Fedora RPMs for Fedora and I noticed what I think is
a rather confusing situation in the 4.0.6 release tree.

In shorewall-4.0.6/ we have, amongst other things:

shorewall-perl-4.0.6-2.tar.bz2
shorewall-perl-4.0.6-1.tar.bz2
shorewall-perl-4.0.6.tar.bz2

with the -X denoting the patch level. The problem is that rpm (and
perhaps deb, not sure) doesn''t allow a "-" in the upstream
version
number, as that is reserved for the separator between the upstream
version number and the package release number. This problem actually
manifest itself in your provided RPMs, eg:

shorewall-perl-4.0.6-2.noarch.rpm

where the patch level has been used for the RPM release number. From a
distro packaging perspective this doesn''t work, because any change to
the package requires an increase in the package release number (the
number after the "-"). The only option for packagers is to turn the
version number into eg. 4.0.6.2. It would be much more helpful if you
would adopt such a convention upstream though - i.e. indicate the patc
level with a 4th minor version number rather than a hyphenated number.
Is that possible?

Also, I notive that in errata/patches/Shorewall-perl/ there is only
patch-perl-4.0.6-1.diff and no patch-perl-4.0.6-2.diff. Is this an
oversight?

Many thanks,
Jonathan.

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On Sat, Dec 08, 2007 at 03:22:21PM +0000, Jonathan Underwood
wrote:
> Hi Tom,
> 
> I co-maintain the Fedora RPMs for Fedora and I noticed what I think is
> a rather confusing situation in the 4.0.6 release tree.
> 
> In shorewall-4.0.6/ we have, amongst other things:
> 
> shorewall-perl-4.0.6-2.tar.bz2
> shorewall-perl-4.0.6-1.tar.bz2
> shorewall-perl-4.0.6.tar.bz2
> 
> with the -X denoting the patch level. The problem is that rpm (and
> perhaps deb, not sure) doesn''t allow a "-" in the
upstream version
> number, as that is reserved for the separator between the upstream
> version number and the package release number. This problem actually
> manifest itself in your provided RPMs, eg:
> 
Actually, .deb does not have this limitation.  However, I have decided
to keep to just the x.y.z pattern for the upstream release (in order to
facilitate different Debian revisions of the same upstream version
having the proper dependency).
> shorewall-perl-4.0.6-2.noarch.rpm
> 
> where the patch level has been used for the RPM release number. From a
> distro packaging perspective this doesn''t work, because any change
to
> the package requires an increase in the package release number (the
> number after the "-"). The only option for packagers is to turn
the
> version number into eg. 4.0.6.2. It would be much more helpful if you
> would adopt such a convention upstream though - i.e. indicate the patc
> level with a 4th minor version number rather than a hyphenated number.
> Is that possible?
> 
What I have done with the Debian packages is to just take the patches
for these minor patch releases and put them in the debian/patches/
folder so that they simply get applied at package build time.  That
allows me to keep the upstream version as just x.y.z.  Then I just
increment the -w for the Debian revision.  Of course, that could
potentially cause some confusion, but I have judged that possibility to
be fairly small, as most people who use the Debian packages will use the
Debian packages exclusively.
> Also, I notive that in errata/patches/Shorewall-perl/ there is only
> patch-perl-4.0.6-1.diff and no patch-perl-4.0.6-2.diff. Is this an
> oversight?
> 
I am not sure about this.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On 08/12/2007, Roberto C. Sánchez <roberto@connexer.com>
wrote:
> What I have done with the Debian packages is to just take the patches
> for these minor patch releases and put them in the debian/patches/
> folder so that they simply get applied at package build time.  That
> allows me to keep the upstream version as just x.y.z.  Then I just
> increment the -w for the Debian revision.  Of course, that could
> potentially cause some confusion, but I have judged that possibility to
> be fairly small, as most people who use the Debian packages will use the
> Debian packages exclusively.
>
Yes, actually, that''s more or less the strategy I''ve adopted
currently
for the Fedora packages, largely to avoid the hyphen problem.

J.

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Jonathan Underwood wrote:
> On 08/12/2007, Roberto C. Sánchez <roberto@connexer.com> wrote:
>> What I have done with the Debian packages is to just take the patches
>> for these minor patch releases and put them in the debian/patches/
>> folder so that they simply get applied at package build time.  That
>> allows me to keep the upstream version as just x.y.z.  Then I just
>> increment the -w for the Debian revision.  Of course, that could
>> potentially cause some confusion, but I have judged that possibility to
>> be fairly small, as most people who use the Debian packages will use
the
>> Debian packages exclusively.
>>
> 
> Yes, actually, that''s more or less the strategy I''ve
adopted currently
> for the Fedora packages, largely to avoid the hyphen problem.
Would it help if I uploaded the source RPM?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On 08/12/2007, Tom Eastep <teastep@shorewall.net>
wrote:
> Jonathan Underwood wrote:
> > On 08/12/2007, Roberto C. Sánchez <roberto@connexer.com> wrote:
> >> What I have done with the Debian packages is to just take the
patches
> >> for these minor patch releases and put them in the debian/patches/
> >> folder so that they simply get applied at package build time. 
That
> >> allows me to keep the upstream version as just x.y.z.  Then I just
> >> increment the -w for the Debian revision.  Of course, that could
> >> potentially cause some confusion, but I have judged that
possibility to
> >> be fairly small, as most people who use the Debian packages will
use the
> >> Debian packages exclusively.
> >>
> >
> > Yes, actually, that''s more or less the strategy I''ve
adopted currently
> > for the Fedora packages, largely to avoid the hyphen problem.
>
> Would it help if I uploaded the source RPM?
No, I''m afraid that wouldn''t address the issue. Fundamentally,
it''s
incorrect to use the package release number (after the hyphen) to
reflect a version number of the software being packaged (in this case
the patchlevel of the tarball). RPM is a bit inflexible in it''s
approach to using a hyphen as the version-release separator, but none
the less, it''s now a well established strategy.

J.

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Jonathan Underwood wrote:
> 
> Also, I notive that in errata/patches/Shorewall-perl/ there is only
> patch-perl-4.0.6-1.diff and no patch-perl-4.0.6-2.diff. Is this an
> oversight?
Jonathan,

No. The patches in the errata have no fixed relationship to the patch releases.

I have modified my build/release tools to create a patch at build time that
is uploaded along with the updated packages. You can see examples at
http://www.shorewall.net/pub/shorewall/development/4.1/shorewall-4.1.2/ (I
didn''t have the tools updated yet when I did the 4.0.2-2 release; I
created
that one manually). It is my intention that distributions apply those
patches consecutively to the base release to produce the distribution
release. The base release tarballs are always available but may have been
moved to the superseded/ directory.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Tom Eastep wrote:
> Jonathan Underwood wrote:
> 
>> Also, I notive that in errata/patches/Shorewall-perl/ there is only
>> patch-perl-4.0.6-1.diff and no patch-perl-4.0.6-2.diff. Is this an
>> oversight?
> 
> Jonathan,
> 
> No. The patches in the errata have no fixed relationship to the patch
releases.
> 
> I have modified my build/release tools to create a patch at build time that
> is uploaded along with the updated packages. You can see examples at
> http://www.shorewall.net/pub/shorewall/development/4.1/shorewall-4.1.2/ (I
> didn''t have the tools updated yet when I did the 4.0.2-2 release;
I created
Of course, I meant the 4.0.6-2 release.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On 08/12/2007, Tom Eastep <teastep@shorewall.net>
wrote:
> It is my intention that distributions apply those
> patches consecutively to the base release to produce the distribution
> release.
OK, thanks Tom, that is a useful clarification, I''ll stick with that
strategy.
> The base release tarballs are always available but may have been
> moved to the superseded/ directory.
this is a bit problematic though -  the source tarball location is one
piece of information that we put in the RPMs - it is useful for things
like the lookaside caching, and auditing of packages etc. It''s really
helpful to have a clear and obvious audit trail from a package as
installed to the upstream sources.


J.

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On 08/12/2007, Jonathan Underwood <jonathan.underwood@gmail.com>
wrote:
> On 08/12/2007, Tom Eastep <teastep@shorewall.net> wrote:
> > It is my intention that distributions apply those
> > patches consecutively to the base release to produce the distribution
> > release.
>
> OK, thanks Tom, that is a useful clarification, I''ll stick with
that strategy.
Actually, I wonder if it wouldn''t be useful to have a clearer
directory structure. Perhaps:

shorewall-4.X.Y  containing the base tarballs
shorewall-4.X.Y/errata  as it currently is
shorewall-4-X.Y/patched  containing the patched tarballs

or some other structure which better reflects the situation.

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Jonathan Underwood wrote:
> On 08/12/2007, Jonathan Underwood <jonathan.underwood@gmail.com>
wrote:
>> On 08/12/2007, Tom Eastep <teastep@shorewall.net> wrote:
>>> It is my intention that distributions apply those
>>> patches consecutively to the base release to produce the
distribution
>>> release.
>> OK, thanks Tom, that is a useful clarification, I''ll stick
with that strategy.
> 
> Actually, I wonder if it wouldn''t be useful to have a clearer
> directory structure. Perhaps:
> 
> shorewall-4.X.Y  containing the base tarballs
> shorewall-4.X.Y/errata  as it currently is
> shorewall-4-X.Y/patched  containing the patched tarballs
> 
> or some other structure which better reflects the situation.
That strategy hides the latest packages where the average fool will never
find them. I would rather have shorewall-4.X.Y/base contain the base packages.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On 08/12/2007, Tom Eastep <teastep@shorewall.net>
wrote:
> Jonathan Underwood wrote:
> > On 08/12/2007, Jonathan Underwood <jonathan.underwood@gmail.com>
wrote:
> >> On 08/12/2007, Tom Eastep <teastep@shorewall.net> wrote:
> >>> It is my intention that distributions apply those
> >>> patches consecutively to the base release to produce the
distribution
> >>> release.
> >> OK, thanks Tom, that is a useful clarification, I''ll
stick with that strategy.
> >
> > Actually, I wonder if it wouldn''t be useful to have a clearer
> > directory structure. Perhaps:
> >
> > shorewall-4.X.Y  containing the base tarballs
> > shorewall-4.X.Y/errata  as it currently is
> > shorewall-4-X.Y/patched  containing the patched tarballs
> >
> > or some other structure which better reflects the situation.
>
> That strategy hides the latest packages where the average fool will never
> find them. I would rather have shorewall-4.X.Y/base contain the base
packages.
Sure, that would work too.

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On Sat, Dec 08, 2007 at 03:49:53PM +0000, Jonathan Underwood
wrote:
> No, I''m afraid that wouldn''t address the issue.
Fundamentally, it''s
> incorrect to use the package release number (after the hyphen) to
> reflect a version number of the software being packaged (in this case
> the patchlevel of the tarball). RPM is a bit inflexible in it''s
> approach to using a hyphen as the version-release separator, but none
> the less, it''s now a well established strategy.
It''s a historical inanity. For the record, dpkg simply considers the
*last* hyphen in the version to be the separator, and you can include
as many other hyphens as you like before that.

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Jonathan Underwood wrote:
> On 08/12/2007, Tom Eastep <teastep@shorewall.net> wrote:
>> Jonathan Underwood wrote:
>>> On 08/12/2007, Jonathan Underwood
<jonathan.underwood@gmail.com> wrote:
>>>> On 08/12/2007, Tom Eastep <teastep@shorewall.net> wrote:
>>>>> It is my intention that distributions apply those
>>>>> patches consecutively to the base release to produce the
distribution
>>>>> release.
>>>> OK, thanks Tom, that is a useful clarification, I''ll
stick with that strategy.
>>> Actually, I wonder if it wouldn''t be useful to have a
clearer
>>> directory structure. Perhaps:
>>>
>>> shorewall-4.X.Y  containing the base tarballs
>>> shorewall-4.X.Y/errata  as it currently is
>>> shorewall-4-X.Y/patched  containing the patched tarballs
>>>
>>> or some other structure which better reflects the situation.
>> That strategy hides the latest packages where the average fool will
never
>> find them. I would rather have shorewall-4.X.Y/base contain the base
packages.
> 
> Sure, that would work too.
In which compression format would you like the base tarballs? gzip or bzip2?

Thanks,
-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On 08/12/2007, Tom Eastep <teastep@shorewall.net>
wrote:
> In which compression format would you like the base tarballs? gzip or
bzip2?
>
It probably doesn''t much matter, but I''d lean towards sticking
with bz2.

Cheers,
Jonathan

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Andrew Suffield wrote:
> On Sat, Dec 08, 2007 at 03:49:53PM +0000, Jonathan Underwood wrote:
>> No, I''m afraid that wouldn''t address the issue.
Fundamentally, it''s
>> incorrect to use the package release number (after the hyphen) to
>> reflect a version number of the software being packaged (in this case
>> the patchlevel of the tarball). RPM is a bit inflexible in
it''s
>> approach to using a hyphen as the version-release separator, but none
>> the less, it''s now a well established strategy.
> 
> It''s a historical inanity. For the record, dpkg simply considers
the
> *last* hyphen in the version to be the separator, and you can include
> as many other hyphens as you like before that.
You can say that all you like, but none of us have the ability to
"fix"
this historical inanity in RPM on all the distros it''s used on.

Personally, i think if a fix is significant enough to be released, it
should have a different version number (e.g. 4.0.6.1 or 4.0.7, depending
on Tom''s preference).

-- 
Paul
<http://paul.gear.dyndns.org>
-- 
Did you know?  Linux is a completely free operating system that provides
a vast array of software "out of the box", and represents a viable
alternative to expensive proprietary software.  For more details, see:
http://consumer.hardocp.com/article.html?art=MTI5OCwxLCxoY29uc3VtZXI


-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On Mon, Dec 10, 2007 at 10:13:54AM +1000, Paul Gear
wrote:
> Andrew Suffield wrote:
> > On Sat, Dec 08, 2007 at 03:49:53PM +0000, Jonathan Underwood wrote:
> >> No, I''m afraid that wouldn''t address the issue.
Fundamentally, it''s
> >> incorrect to use the package release number (after the hyphen) to
> >> reflect a version number of the software being packaged (in this
case
> >> the patchlevel of the tarball). RPM is a bit inflexible in
it''s
> >> approach to using a hyphen as the version-release separator, but
none
> >> the less, it''s now a well established strategy.
> > 
> > It''s a historical inanity. For the record, dpkg simply
considers the
> > *last* hyphen in the version to be the separator, and you can include
> > as many other hyphens as you like before that.
> 
> You can say that all you like, but none of us have the ability to
"fix"
> this historical inanity in RPM on all the distros it''s used on.
Yes, it is an unfixable historical inanity.

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On Mon, Dec 10, 2007 at 10:13:54AM +1000, Paul Gear
wrote:
> Andrew Suffield wrote:
> > On Sat, Dec 08, 2007 at 03:49:53PM +0000, Jonathan Underwood wrote:
> >> No, I''m afraid that wouldn''t address the issue.
Fundamentally, it''s
> >> incorrect to use the package release number (after the hyphen) to
> >> reflect a version number of the software being packaged (in this
case
> >> the patchlevel of the tarball). RPM is a bit inflexible in
it''s
> >> approach to using a hyphen as the version-release separator, but
none
> >> the less, it''s now a well established strategy.
> > 
> > It''s a historical inanity. For the record, dpkg simply
considers the
> > *last* hyphen in the version to be the separator, and you can include
> > as many other hyphens as you like before that.
> 
> You can say that all you like, but none of us have the ability to
"fix"
> this historical inanity in RPM on all the distros it''s used on.
> 
Well, we could all switch to .deb-based distros :-p
> Personally, i think if a fix is significant enough to be released, it
> should have a different version number (e.g. 4.0.6.1 or 4.0.7, depending
> on Tom''s preference).
> 
While that is certainly debatable, I think that catering to the lowest
common denominator (for lack of a better term) is probably the best
approach.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Gear wrote:
> Andrew Suffield wrote:
>> On Sat, Dec 08, 2007 at 03:49:53PM +0000, Jonathan Underwood wrote:
>>> No, I''m afraid that wouldn''t address the issue.
Fundamentally, it''s
>>> incorrect to use the package release number (after the hyphen) to
>>> reflect a version number of the software being packaged (in this
case
>>> the patchlevel of the tarball). RPM is a bit inflexible in
it''s
>>> approach to using a hyphen as the version-release separator, but
none
>>> the less, it''s now a well established strategy.
>> It''s a historical inanity. For the record, dpkg simply
considers the
>> *last* hyphen in the version to be the separator, and you can include
>> as many other hyphens as you like before that.
Rpm release number is reserved for package maintainer only.

I don''t really see any reason to release new tarball when there is fix
for latest stable version. If somebody install from tarball it''s very
convinient to update file on filesystem by downloading it and compying
over old version.

And for pacakge maintainers it''s as  easy to take patch fixing problem
and add it to rpm or dep and build new release of package.

If new tarball is generated there need to be new software release. And
that applies to last minute change after package was send to wild. There
should never be two pacakges with different content and same versionn
number. So if 4.0.7 release is broken and it''s found out in 2 hours,
there should be immidiately new 4.0.8 release with fix. Not two
different 4.0.7 tarballs.

Imho version numbers don''t cost very much. And immediate new release is
better than confusion which is caused by deifferent tar revisions around
:-).

- --
Tuomo Soini <tis@foobar.fi>
Linux and network services
+358 40 5240030
Foobar Oy <http://foobar.fi/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFHXThkTlrZKzwul1ERAopCAJ9HqV4u525MefnykDm4HoaXWtWVjgCfR0EJ
gnJBj+xYefzyH0DwrkyLVVE=uDhv
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On Sun, 2007-12-09 at 20:25 -0500, Roberto C. Sánchez
wrote:
> On Mon, Dec 10, 2007 at 10:13:54AM +1000, Paul Gear wrote:
> > Personally, i think if a fix is significant enough to be released, it
> > should have a different version number (e.g. 4.0.6.1 or 4.0.7,
depending
> > on Tom's preference).
> 
> While that is certainly debatable, I think that catering to the lowest
> common denominator (for lack of a better term) is probably the best
> approach.
Exactly. Why use patch levels upstream at all?

Tom does not need to publish patched versions. He is the authoritative,
official instance to release a new version. Thus, 4.0.6.1 is perfectly
fine a version number. The diff can be published as well, but IMHO, we
should stick to "real" version numbers and releases upstream.

Use a dot instead of a hyphen, and there is no confusion. :)

  karsten


-- 
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      http://www.catb.org/~esr/faqs/smart-questions.html
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      http://www.chiark.greenend.org.uk/~sgtatham/bugs.html


-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Shorewall-devel mailing list
Shorewall-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-devel

Tuomo Soini wrote:
> 
> Imho version numbers don''t cost very much. 
With Shorewall, a new full version number is not cheap; it takes a couple of
hours to produce and results in new versions of all of the tarballs and
RPMs, even if only one product changed.

I propose that beginning with 4.0.7 that I adopt the kernel''s naming
convention; X.Y.Z is the base release; patch tarballs (and RPMs) are
X.Y.Z.1, X.Y.Z.2, ...

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On Mon, 2007-12-10 at 08:05 -0800, Tom Eastep wrote:
> I propose that beginning with 4.0.7 that I adopt the kernel''s
naming
> convention; X.Y.Z is the base release; patch tarballs (and RPMs) are
> X.Y.Z.1, X.Y.Z.2, ...
+1

That''s exactly what I posted earlier today anyway. :)

  Karsten


-- 
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      http://www.catb.org/~esr/faqs/smart-questions.html
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      http://www.chiark.greenend.org.uk/~sgtatham/bugs.html


-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Karsten Bräckelmann wrote:
> On Mon, 2007-12-10 at 08:05 -0800, Tom Eastep wrote:
>> I propose that beginning with 4.0.7 that I adopt the kernel''s
naming
>> convention; X.Y.Z is the base release; patch tarballs (and RPMs) are
>> X.Y.Z.1, X.Y.Z.2, ...
> 
> +1
> 
> That''s exactly what I posted earlier today anyway. :)
I know.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Tom Eastep wrote:
> Tuomo Soini wrote:
> 
>> Imho version numbers don''t cost very much. 
> 
> With Shorewall, a new full version number is not cheap; it takes a couple
of
> hours to produce and results in new versions of all of the tarballs and
> RPMs, even if only one product changed.
> 
> I propose that beginning with 4.0.7 that I adopt the kernel''s
naming
> convention; X.Y.Z is the base release; patch tarballs (and RPMs) are
> X.Y.Z.1, X.Y.Z.2, ...
The RPMs that I produce for SuSE, TurboLinux, etc. will still encode the
patch level in the release number. So the RPM corresponding to X.Y.Z.n will
be shorewall-xxx-X.Y.Z-n.noarch.rpm rather than
shorewall-xxx-X.Y.Z.n-1.noarch.rpm

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Tom Eastep wrote:
> Tom Eastep wrote:
>> Tuomo Soini wrote:
>>
>>> Imho version numbers don''t cost very much. 
>> With Shorewall, a new full version number is not cheap; it takes a
couple of
>> hours to produce and results in new versions of all of the tarballs and
>> RPMs, even if only one product changed.
>>
>> I propose that beginning with 4.0.7 that I adopt the kernel''s
naming
>> convention; X.Y.Z is the base release; patch tarballs (and RPMs) are
>> X.Y.Z.1, X.Y.Z.2, ...
> 
> The RPMs that I produce for SuSE, TurboLinux, etc. will still encode the
> patch level in the release number. So the RPM corresponding to X.Y.Z.n will
> be shorewall-xxx-X.Y.Z-n.noarch.rpm rather than
> shorewall-xxx-X.Y.Z.n-1.noarch.rpm
One other issue to decide; the kernel patches are cumulative -- should
Shorewall patches also be cumulative so that distributions only have to
apply the latest patch against the base release?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On Mon, 2007-12-10 at 11:29 -0800, Tom Eastep wrote:
> One other issue to decide; the kernel patches are cumulative -- should
> Shorewall patches also be cumulative so that distributions only have to
> apply the latest patch against the base release?
As far as distro packagers are concerned, I believe it doesn''t make
much
of a difference. They will either need to add a new patch, or get rid of
the old one and substitute by the new...

For anyone out there actually using the tarball releases however,
cumulative patches would result in more work, if they are tracking the
code closely. After all, the new patch doesn''t just apply cleanly. The
old one(s) need to be reverted first, to apply the latest fixes.


The GNOME project for example offers a diff between each release and its
predecessor (if any) of the same $MAJOR.$MINOR version.

Personally, I''d go with a patch that includes the fixes for the latest
version. However, I am not a distro packager. :)

  Karsten


-- 
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      http://www.catb.org/~esr/faqs/smart-questions.html
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      http://www.chiark.greenend.org.uk/~sgtatham/bugs.html


-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On Mon, Dec 10, 2007 at 11:29:28AM -0800, Tom Eastep
wrote:
> One other issue to decide; the kernel patches are cumulative -- should
> Shorewall patches also be cumulative so that distributions only have to
> apply the latest patch against the base release?
The primary aim of the kernel patch distribution system is to reduce
the stupidly huge bandwidth load on kernel.org as much as possible. I
don''t think that''s an issue here, so what they do
isn''t really
relevant. I presume your goal is to maximise convinience for people
who aren''t using vendor packages, so the question is: what are these
people going to be doing? Not being one of them, I''m not really sure.

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On Mon, Dec 10, 2007 at 11:29:28AM -0800, Tom Eastep
wrote:
> 
> One other issue to decide; the kernel patches are cumulative -- should
> Shorewall patches also be cumulative so that distributions only have to
> apply the latest patch against the base release?
> 
I don''t have a preference one way or the other.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Karsten Bräckelmann wrote:
> On Mon, 2007-12-10 at 11:29 -0800, Tom Eastep wrote:
>> One other issue to decide; the kernel patches are cumulative -- should
>> Shorewall patches also be cumulative so that distributions only have to
>> apply the latest patch against the base release?
> 
> As far as distro packagers are concerned, I believe it doesn''t
make much
> of a difference. They will either need to add a new patch, or get rid of
> the old one and substitute by the new...
> 
> For anyone out there actually using the tarball releases however,
> cumulative patches would result in more work, if they are tracking the
> code closely. After all, the new patch doesn''t just apply cleanly.
The
> old one(s) need to be reverted first, to apply the latest fixes.
The tarballs are so small that anyone using them would undoubtedly just
download the updated tarball.
> 
> 
> The GNOME project for example offers a diff between each release and its
> predecessor (if any) of the same $MAJOR.$MINOR version.
Shorewall has always done that as well.
> 
> Personally, I''d go with a patch that includes the fixes for the
latest
> version. However, I am not a distro packager. :)
> 
Maybe I should just avoid this whole issue just by never adding new features
in dot releases. That is really the only reason that we have broken dot
releases in the first place. Eliminate that problem and I essentially
eliminate the need for patch releases. The first few dot releases in a major
release tend to come in fairly rapid succession anyway.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On Mon, 2007-12-10 at 13:01 -0800, Tom Eastep wrote:
> Karsten Bräckelmann wrote:
> > For anyone out there actually using the tarball releases however,
> > cumulative patches would result in more work, if they are tracking the
> > code closely. After all, the new patch doesn't just apply cleanly.
The
> > old one(s) need to be reverted first, to apply the latest fixes.
> 
> The tarballs are so small that anyone using them would undoubtedly just
> download the updated tarball.
Well, I once applied a patch, that fixed inline Shell code in the params
file. On the other hand, however, I always have been using your vanilla
RPMs, rather than the tarballs.

> > The GNOME project for example offers a diff between each release and
its
> > predecessor (if any) of the same $MAJOR.$MINOR version.
> 
> Shorewall has always done that as well.
So we got the answer to the question, no? :)

> Maybe I should just avoid this whole issue just by never adding new
features
> in dot releases. [...]
By that you mean the third number, $MICRO, rather than the tiny-fix
forth number? I seem to recall, that has been your plan more than once
already. ;-)

  Karsten


-- 
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      http://www.catb.org/~esr/faqs/smart-questions.html
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      http://www.chiark.greenend.org.uk/~sgtatham/bugs.html


-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Shorewall-devel mailing list
Shorewall-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-devel

Roberto C. Sánchez wrote:
> On Mon, Dec 10, 2007 at 11:29:28AM -0800, Tom Eastep wrote:
>> One other issue to decide; the kernel patches are cumulative -- should
>> Shorewall patches also be cumulative so that distributions only have to
>> apply the latest patch against the base release?
>>
> I don''t have a preference one way or the other.
Okay - I''ll wait until Jonathan weighs in then to make a decision.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On 10/12/2007, Tom Eastep <teastep@shorewall.net>
wrote:
> Roberto C. Sánchez wrote:
> > On Mon, Dec 10, 2007 at 11:29:28AM -0800, Tom Eastep wrote:
> >> One other issue to decide; the kernel patches are cumulative --
should
> >> Shorewall patches also be cumulative so that distributions only
have to
> >> apply the latest patch against the base release?
> >>
> > I don''t have a preference one way or the other.
>
> Okay - I''ll wait until Jonathan weighs in then to make a decision.
>From my perspective it doesn''t make a huge difference either way.
It''s
marginally less work to apply a singe cumulative patch. On the other
hand, a series of fine grained patches is easier to debug if there''s a
problem. But hopefully there shouldn''t be problems introduced with the
patches. A series of fine grained patches is probably also better from
an audit point of view... so a minor preference in that direction, but
no strong feeling.

J.

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Jonathan Underwood wrote:
> On 10/12/2007, Tom Eastep <teastep@shorewall.net> wrote:
>> Roberto C. Sánchez wrote:
>>> On Mon, Dec 10, 2007 at 11:29:28AM -0800, Tom Eastep wrote:
>>>> One other issue to decide; the kernel patches are cumulative --
should
>>>> Shorewall patches also be cumulative so that distributions only
have to
>>>> apply the latest patch against the base release?
>>>>
>>> I don''t have a preference one way or the other.
>> Okay - I''ll wait until Jonathan weighs in then to make a
decision.
> 
>>From my perspective it doesn''t make a huge difference either
way. It''s
> marginally less work to apply a singe cumulative patch. On the other
> hand, a series of fine grained patches is easier to debug if
there''s a
> problem. But hopefully there shouldn''t be problems introduced with
the
> patches. A series of fine grained patches is probably also better from
> an audit point of view... so a minor preference in that direction, but
> no strong feeling.
I have no preference either way either; my build tools can do it either
way. So Jonathan''s slight preference for fine grained patches means
we''ll do it that way.

Thanks,
-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

On Tue, Dec 11, 2007 at 12:42:52AM +0000, Jonathan Underwood
wrote:
> On the other
> hand, a series of fine grained patches is easier to debug if
there''s a
> problem. But hopefully there shouldn''t be problems introduced with
the
> patches. A series of fine grained patches is probably also better from
> an audit point of view... so a minor preference in that direction, but
> no strong feeling.
It is entirely trivial to convert from one to the other when needed
using interdiff and combinediff, so exceptional cases aren''t
important.

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

> Jonathan Underwood wrote:
>> On 10/12/2007, Tom Eastep <teastep@shorewall.net> wrote:
>>> Roberto C. Sánchez wrote:
>>>> On Mon, Dec 10, 2007 at 11:29:28AM -0800, Tom Eastep wrote:
>>>>> One other issue to decide; the kernel patches are
cumulative --
>>>>> should
>>>>> Shorewall patches also be cumulative so that distributions
only have
>>>>> to
>>>>> apply the latest patch against the base release?
>>>>>
>>>> I don''t have a preference one way or the other.
>>> Okay - I''ll wait until Jonathan weighs in then to make a
decision.
>>
>>>From my perspective it doesn''t make a huge difference
either way. It''s
>> marginally less work to apply a singe cumulative patch. On the other
>> hand, a series of fine grained patches is easier to debug if
there''s a
>> problem. But hopefully there shouldn''t be problems introduced
with the
>> patches. A series of fine grained patches is probably also better from
>> an audit point of view... so a minor preference in that direction, but
>> no strong feeling.
>
> I have no preference either way either; my build tools can do it either
> way. So Jonathan''s slight preference for fine grained patches
means
> we''ll do it that way.
So what will be the effective change in the end? I''m RPM packaging
shorewall for years and it has never been easier than it is now with the
patches we get. So why change again, is it worth the effort?

Simon


-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Simon Matter wrote:
> 
> So what will be the effective change in the end? I''m RPM packaging
> shorewall for years and it has never been easier than it is now with the
> patches we get. So why change again, is it worth the effort?
> 
The effort is aimed at:

a) providing up-to-date packages (including tarballs) from Shorewall.net so
that people who download the latest packages don''t have to apply
patches.
b) accomodating the Debian packager in that the Debian packaging system
wants patches that can be applied with "-p1" while the errata patches
are
applied with "-p0".

-Toom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php