Re: [Fedora-packaging] Re: (fix typos) Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

2015-11-30 Thread Sérgio Basto 
Hi, 

On Seg, 2015-11-30 at 12:15 +0100, Dominik 'Rathann' Mierzejewski
wrote:
> On Tuesday, 24 November 2015 at 14:56, Sérgio Basto wrote:
> > Switching to packag...@lists.fedoraproject.org 
> [...]
> > In this link http://fedoraproject.org/wiki/Packaging:NamingGuidelin
> > es#Pre-Release_packages ;
> > where we read :
> > 
> > Release Tag for Pre-Release Packages: 
> > 
> > 0.%{X}.%{alphatag}%{?dist}   
> > 
> > And I'm proposing : 
> > 
> > 0[.%{X}].%{alphatag}[.%{Y}]%{?dist} 
> > 
> > is just better IMHO .
> 
> Personally, I think it's too complicated due to the optional nature
> of X and Y parts and it's just as easy to get wrong if subsequent
> alphatag breaks release monontonicity and the package maintainer
> doesn't notice it.
> 
> With X being currently mandatory, at least you know you must always
> increase it every time you update the package, so monotonicity is
> preserved.

Other argument that I forgot to mention is: this is an extension of
first version so nobody needs change his package naming and is an
extension in two ways :
1 - Possibility of begin with 0 , before was need be: 0.%{X} 
2 - Possibility of write in right . 

The current: 0.%{X}.%{alphatag}%{?dist}
Extension 1: 0[.%{X}].%{alphatag}%{?dist}
Extension 2: 0[.%{X}].%{alphatag}[.%{Y}]%{?dist}

I'd like to have permission to use in some of "my" packages.

> Regards,
> Dominik
-- 
Sérgio M. B.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [Fedora-packaging] Re: (fix typos) Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

2015-11-30 Thread Dominik 'Rathann' Mierzejewski 
On Tuesday, 24 November 2015 at 14:56, Sérgio Basto wrote:
> Switching to packag...@lists.fedoraproject.org 
[...]
> In this link 
> http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages 
> where we read :
> 
> Release Tag for Pre-Release Packages: 
> 
> 0.%{X}.%{alphatag}%{?dist}   
> 
> And I'm proposing : 
> 
> 0[.%{X}].%{alphatag}[.%{Y}]%{?dist} 
> 
> is just better IMHO .

Personally, I think it's too complicated due to the optional nature
of X and Y parts and it's just as easy to get wrong if subsequent
alphatag breaks release monontonicity and the package maintainer
doesn't notice it.

With X being currently mandatory, at least you know you must always
increase it every time you update the package, so monotonicity is
preserved.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: (fix typos) Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

2015-11-24 Thread Sérgio Basto 
On Ter, 2015-11-24 at 08:18 -0500, Jared K. Smith wrote:
> 
> On Mon, Nov 23, 2015 at 8:47 PM, Sérgio Basto 
> wrote:
> > we have two counters, one when upstream change the source
> > other when we rebuild the package, it will be better readable, to
> > understand if the upstream had updates or not.
> > 
> 
> Maybe I'm not understanding you well, but we *do* have two
> counters... in fact, we have *three*.  We have epoch, version, and
> release.  When an upstream community puts out a newer version of the
> software, the version number should increase.  When the packager puts
> out a new package with the same version number, she/he should
> increase the release number.  This is why pre-release software should
> have a release number that begins with "0.", so that when the
> production release happens, the release number can start at "1". 
> Last but not least, Epoch can be used to override the version and
> release numbers in special cases where the version and release
> numbers of a newer release don't sort to the top.  (One such example
> might be if we needed to downgrade a particular package for some
> reason.)
> 
> Does that help make things more clear?

Use epoch is one solution but in my mind, epoch is for breakage, we
should avoid use epoch, epoch was needed to install kde4 over F23 :) 
Thanks,
-- 
Sérgio M. B.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: (fix typos) Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

2015-11-24 Thread Jared K. Smith 
On Mon, Nov 23, 2015 at 8:47 PM, Sérgio Basto  wrote:

> we have two counters, one when upstream change the source
> other when we rebuild the package, it will be better readable, to
> understand if the upstream had updates or not.
>


Maybe I'm not understanding you well, but we *do* have two counters... in
fact, we have *three*.  We have epoch, version, and release.  When an
upstream community puts out a newer version of the software, the version
number should increase.  When the packager puts out a new package with the
same version number, she/he should increase the release number.  This is
why pre-release software should have a release number that begins with
"0.", so that when the production release happens, the release number can
start at "1".  Last but not least, Epoch can be used to override the
version and release numbers in special cases where the version and release
numbers of a newer release don't sort to the top.  (One such example might
be if we needed to downgrade a particular package for some reason.)

Does that help make things more clear?

--
Jared Smith
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: (fix typos) Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

2015-11-24 Thread Sérgio Basto 
Switching to packag...@lists.fedoraproject.org 

On Ter, 2015-11-24 at 01:47 +, Sérgio Basto wrote:
> On Seg, 2015-11-23 at 09:39 +0100, Dominik 'Rathann' Mierzejewski
> wrote:
> > On Sunday, 22 November 2015 at 00:46, Sérgio Basto wrote:
> > > On Sex, 2015-11-20 at 15:18 +0100, Tomas Mraz wrote:
> > > > On Čt, 2015-11-19 at 20:59 +, Sérgio Basto wrote:
> > > > > On Qua, 2015-11-18 at 17:11 -0600, Jason L Tibbitts III
> > > > > wrote:
> > > > > > > > > > > "SB" == Sérgio Basto  writes:
> > > > > > 
> > > > > > SB> When we fix the .spec and don't change the source, we
> > > > > > bump
> > > > > > rightmost
> > > > > > SB> version, when we change the source, we bump the left
> > > > > > version,
> > > > > > so
> > > > > > we
> > > > > > SB> can distinguish when we update the source and when we
> > > > > > updated
> > > > > > the
> > > > > > SB> .spec, this contrast for me is important.
> > > > > > 
> > > > > > For me, the simple rule that a Release: tag less than 1
> > > > > > implies
> > > > > > prerelease software, while a Release: tag of 1 or greater
> > > > > > implies
> > > > > > a
> > > > > > post-release package, is important.  So far the proponents
> > > > > > of
> > > > > > this
> > > > > > change haven't shown what things would actually look like
> > > > > > after
> > > > > > this
> > > > > > change, so it's hard for me to come up with a reason to
> > > > > > change my
> > > > > > opinion.
> > > > > 
> > > > > prerelease numbering can't begin with 0 and increased to 0.1
> > > > > because :
> > > > > 
> > > > > next version of foo-0.b would be foo-0.1.b and "b">1 
> > > > 
> > > > Nope, 1>"b" in rpm version compare.
> > 
> > Even so, we shouldn't depend on upstream preserving sorting order
> > in
> > their pre-release suffixes. Numerical sorting is always monotonous.
> > 
> > > If so, we could begging numeration with 0 for pre-release: 
> > > 
> > > foo-0.c -> foo-0.c.1 -> foo-0.1.b -> foo-0.1.b.1 -> foo-0.2.a ->
> > > foo-
> > > 0.2.a.1 
> > 
> > I don't understand why you want to introduce another level of
> > numbering.
> > What's wrong with the current guideline?
> 
> I'd like improve for cases that upstream doesn't make a release and
> the package stays forever in a pre-release, this happens a lot with
> old projects that are half dead upstream, instead of have just one
> counter, we have two counters, one when upstream change the source
> other when we rebuild the package, it will be better readable, to
> understand if the upstream had updates or not.


In this link 
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages 
where we read :

Release Tag for Pre-Release Packages: 

0.%{X}.%{alphatag}%{?dist}   

And I'm proposing : 

0[.%{X}].%{alphatag}[.%{Y}]%{?dist} 

is just better IMHO .


> Best regards,
> -- 
> Sérgio M. B.
> 
> 
-- 
Sérgio M. B.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

(fix typos) Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

2015-11-23 Thread Sérgio Basto 
On Seg, 2015-11-23 at 09:39 +0100, Dominik 'Rathann' Mierzejewski
wrote:
> On Sunday, 22 November 2015 at 00:46, Sérgio Basto wrote:
> > On Sex, 2015-11-20 at 15:18 +0100, Tomas Mraz wrote:
> > > On Čt, 2015-11-19 at 20:59 +, Sérgio Basto wrote:
> > > > On Qua, 2015-11-18 at 17:11 -0600, Jason L Tibbitts III wrote:
> > > > > > > > > > "SB" == Sérgio Basto  writes:
> > > > > 
> > > > > SB> When we fix the .spec and don't change the source, we
> > > > > bump
> > > > > rightmost
> > > > > SB> version, when we change the source, we bump the left
> > > > > version,
> > > > > so
> > > > > we
> > > > > SB> can distinguish when we update the source and when we
> > > > > updated
> > > > > the
> > > > > SB> .spec, this contrast for me is important.
> > > > > 
> > > > > For me, the simple rule that a Release: tag less than 1
> > > > > implies
> > > > > prerelease software, while a Release: tag of 1 or greater
> > > > > implies
> > > > > a
> > > > > post-release package, is important.  So far the proponents of
> > > > > this
> > > > > change haven't shown what things would actually look like
> > > > > after
> > > > > this
> > > > > change, so it's hard for me to come up with a reason to
> > > > > change my
> > > > > opinion.
> > > > 
> > > > prerelease numbering can't begin with 0 and increased to 0.1
> > > > because :
> > > > 
> > > > next version of foo-0.b would be foo-0.1.b and "b">1 
> > > 
> > > Nope, 1>"b" in rpm version compare.
> 
> Even so, we shouldn't depend on upstream preserving sorting order in
> their pre-release suffixes. Numerical sorting is always monotonous.
> 
> > If so, we could begging numeration with 0 for pre-release: 
> > 
> > foo-0.c -> foo-0.c.1 -> foo-0.1.b -> foo-0.1.b.1 -> foo-0.2.a ->
> > foo-
> > 0.2.a.1 
> 
> I don't understand why you want to introduce another level of
> numbering.
> What's wrong with the current guideline?

I'd like improve for cases that upstream doesn't make a release and
the package stays forever in a pre-release, this happens a lot with
old projects that are half dead upstream, instead of have just one
counter, we have two counters, one when upstream change the source
other when we rebuild the package, it will be better readable, to
understand if the upstream had updates or not.

Best regards,
-- 
Sérgio M. B.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct