On 06/15/2015 01:36 PM, Richard W.M. Jones wrote:
>> You can set arbitrary version numbers on subpackages, so this isn't
>> really an issue.
>
> Blimey, so you can. That's a pretty obscure feature of RPM! I wonder
> if any packages use it?
It's quite common, a quick count yields 5257 subpackag
On Mon, Jun 15, 2015 at 01:03:58PM +0200, Miroslav Suchý wrote:
> Dne 7.5.2015 v 10:17 Richard W.M. Jones napsal(a):
> > For this reason, Fedora packages three different Unison branches in
> > separate packages:
> >
> > - unison213 (currently Unison 2.13.16)
> > - unison227 (currently Unison 2.2
On Mon, Jun 15, 2015 at 01:13:23PM +0200, Florian Weimer wrote:
> On 06/15/2015 12:44 PM, Richard W.M. Jones wrote:
> >
> > I did a bit of experimental packaging of Unison over the weekend, and
> > -- proving the importance of creating a mock-up -- I came to realize
> > why my proposal was wrong:
On 06/15/2015 12:44 PM, Richard W.M. Jones wrote:
>
> I did a bit of experimental packaging of Unison over the weekend, and
> -- proving the importance of creating a mock-up -- I came to realize
> why my proposal was wrong:
>
> - Subpackages would have the wrong version number. eg: If the main
Dne 7.5.2015 v 10:17 Richard W.M. Jones napsal(a):
> For this reason, Fedora packages three different Unison branches in
> separate packages:
>
> - unison213 (currently Unison 2.13.16)
> - unison227 (currently Unison 2.27.57)
> - unison240 (currently Unison 2.40.128)
> - There was a "unison" p
I did a bit of experimental packaging of Unison over the weekend, and
-- proving the importance of creating a mock-up -- I came to realize
why my proposal was wrong:
- Subpackages would have the wrong version number. eg: If the main
package was unison-2.48.3-1.fc23, the Unison 2.40 branch su
I use Unison, and I have 2.40.x in Fedora and on the CentOS box I sync with
on the other side. And since Debian and Ubuntu also ship 2.40, that would
work equally well.
Truthfully I didn't know there was a stable version 2.48. If I could get it
on CentOS and Debian, I'd be happy to run it in Fedor
On Thu, May 07, 2015 at 07:49:34PM +0100, Richard W.M. Jones wrote:
> I don't think your logic is flawed, but there do appear to be more
> builds for the combined "unison-legacy" package -- see my figures
> here, assuming "unison-legacy" would cover the first three packages.
Actually, your figures
On Thu, May 07, 2015 at 02:19:27PM -0400, Matthew Miller wrote:
> On Thu, May 07, 2015 at 07:01:44PM +0100, Richard W.M. Jones wrote:
> > I think the problem is almost everyone would be using unison-legacy,
> > since that would be the only version compatible with the broader
> > ecosystem of Unison
On Thu, May 07, 2015 at 07:01:44PM +0100, Richard W.M. Jones wrote:
> I think the problem is almost everyone would be using unison-legacy,
> since that would be the only version compatible with the broader
> ecosystem of Unison servers (by which I mean Debian).
>
> So it doesn't really solve the "
On Thu, May 07, 2015 at 01:59:10PM -0400, Matthew Miller wrote:
> On Thu, May 07, 2015 at 11:50:02AM -0600, Kevin Fenzi wrote:
> > > I think the issue is that none of those versions are getting updates
> > > anymore. They are dead code... any fix that is going to be in one is
> > > probably going t
On Thu, May 07, 2015 at 11:50:02AM -0600, Kevin Fenzi wrote:
> I don't think just adding new packages is that big a deal to save
> everyone from this.
I think the main problem is that I'm not motivated to go through the
new package process for unison245, unison247 or unison248, and
evidently nor
On Thu, May 07, 2015 at 11:50:02AM -0600, Kevin Fenzi wrote:
> > I think the issue is that none of those versions are getting updates
> > anymore. They are dead code... any fix that is going to be in one is
> > probably going to be in all of them so they would all need it.
> I mean that anytime you
On Thu, May 07, 2015 at 08:41:25AM -0600, Kevin Fenzi wrote:
> Well, just as mentioned in the previous thread, if you do things this
> way it means every user of any unison will have to get a useless update
> everytime any version of unison in your combined package updates for
> any reason. Thats p
On Thu, 7 May 2015 08:58:45 -0600
Stephen John Smoogen wrote:
> > Well, just as mentioned in the previous thread, if you do things
> > this way it means every user of any unison will have to get a
> > useless update everytime any version of unison in your combined
> > package updates for any reas
subpackages would have the
>>> same names as now (unison227 etc), making this a compatible update for
>>> existing Fedora Unison users.
>>>
>>> This way I only need to submit a single new package review, we can
>>> delete the unison2xx source package
king this a compatible update for
>> existing Fedora Unison users.
>>
>> This way I only need to submit a single new package review, we can
>> delete the unison2xx source packages, and there'll be a single place
>> for unison in Fedora for ever more.
>>
>>
sources and build
> different binary subpackages. The binary subpackages would have the
> same names as now (unison227 etc), making this a compatible update for
> existing Fedora Unison users.
>
> This way I only need to submit a single new package review, we can
> delete the
> same names as now (unison227 etc), making this a compatible update for
> existing Fedora Unison users.
>
> This way I only need to submit a single new package review, we can
> delete the unison2xx source packages, and there'll be a single place
> for unison in Fedora for eve
we can
delete the unison2xx source packages, and there'll be a single place
for unison in Fedora for ever more.
Discuss ...
Rich.
[1] BTW there is a COPR build of unison248 if you search for it.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my progra
20 matches
Mail list logo
