[ATrpms-devel] myth development sanction regular trunk rpm => merging myth and plugins?

Axel Thimm Axel.Thimm at ATrpms.net
Fri Nov 10 11:45:29 CET 2006


On Fri, Nov 10, 2006 at 02:13:10AM -0800, Tim Fenn wrote:
> On Fri, Nov 10, 2006 at 01:06:58AM +0100, Axel Thimm wrote:
> > On Thu, Nov 09, 2006 at 01:33:46PM -0800, Tim Fenn wrote:
> > > On Thu, Nov 09, 2006 at 09:08:30PM +0100, Axel Thimm wrote:
> > > > 
> > > > I've been asked to regularily offer trunk packages in a designated
> > > > area (e.g. the bleeding section). The packages are also to always be
> > > > built with full debug settings.
> > > > 
> > > > In order to do this one must be careful to not mix regular and trunk
> > > > builds and having mythtv+plugins split in two builds may pick up the
> > > > wrong packages.
> > > > 
> > > > The reason mythtv and mythplugins are separate packages are historical
> > > > (mythplugins was even several source tarballs once) and due to (some)
> > > > plugins having a different release cycle once, e.g. there could be
> > > > 0.20.1 for some plugins and some + core would remain at 0.20. Having
> > > > them separate helped reducing the builds of the core package.
> > > > 
> > > > But since the advent of fixes branches the core package need to be
> > > > rebuilt each time just the same, so some of the reasons melt away, and
> > > > the new arguments for keeping it all under one src.rpm change the
> > > > balance.
> > > > 
> > > > So, what do you think? Merge mythtv and mythplugins into one build?
> > > 
> > > This seems more in-line with how current myth development works - just
> > > track the 0.20-fixes branch as one big package...
> > > 
> > > But how would that help one (or better yet, a package manager)
> > > differentiate whether it was dealing with the stable (fixes)
> > > vs. bleeding (trunk) builds?
> > 
> > That's the easy part: The usual build of for example 20-fixes gets
> > into atrpms-stable and the trunk build into atrpms-bleeding.
> 
> What I meant to ask (and failed to explain properly): how will the
> rpms be tagged such that yum/apt/smart will know the difference
> between the two?  i.e. if I enable atrpms-bleeding, how will the
> bleeding rpm supersede the stable version (since there is no technical
> version number...)?

For example the atrpms-stable packages will be mythtv-0.20-150 and the
ones in bleeding mythtv-0.21-151_trunk or similar. E.g. the trunk
packages will be rpm-newer (they effectively are anyway), and they
will get some ugly tag to remind users of what they are running and to
allow for quick checks in diagnosis ("What does rpm -q mythtv say?").
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-devel/attachments/20061110/acb7ea53/attachment.bin 


More information about the atrpms-devel mailing list