RE: Version bump policies and beta packages in stable branch

I like it. You write that Xeta should "select a tree-specified default" for
virtual dependencies, and I think such possibility is a must-have with a
solution like this.
An example scenario that warrants it is if MySQL (or another virtual
dependency) is not the desired end result in itself. If a package such as qt
is requested to be compiled with MySQL support, then Xeta should default to
the 1 version that tree maintainers find most suitable for the overall
purpose of the tree. For a production tree that would almost certainly be
v4.0 of MySQL, but for an "I-like-to-live-life-dangerously" tree it could be
v5.0. This is of course assuming that qt will compile against all 3 versions
of MySQL, which I think is unlikely, but let's pretend for the moment that
it does. :)  Of course the possibility to block deps known not to work
should still be there, and it is iirc.
I have a request, and that is that configuration of such tree-specified
defaults get separated from the other configuration options. It would be
best to provide a conf file that can be freely tampered with by user, and a
number of other files where the typical "If you edit this file you will void
your support" statement is. (If we were nasty we could even make Xeta do MD5
digest of these files and send them back to support server live for
user/customer to prove that he didn't mess with anything he shouldn't be
messing with :))
So anyway that would mean at least 1 conf file per tree that user syncs up
with and combines, so override policies and stuff like that would be in
demand. Of course this still leaves the quirk for people who never ever wish
to move from 4.0 to 4.1, but it somehow seems easier to reason with now. If
the tree conf file is versioned like the xbuilds are, then a user can stay
with a distribution version and never get untimely updates shoved in his
face. 

Frantz Dhin


> -----Original Message-----
> From: [email protected] [mailto:zynaut-
> [email protected]] On Behalf Of Low Zhen Lin
> Sent: 24. januar 2004 11:58
> To: [email protected]
> Subject: Re: Version bump policies and beta packages in stable branch
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I can offer the technical solution:
> 
> MySQL comes in three mutually incompatible branches: 4.0, 4.1 and 5.0.
> 
> Thus, the XBuild tree will have three MySQL projects: mysql-4.0,
> mysql-4.1 and mysql-5.0.
> 
> 'mysql' is an alias for all three projects. Thus, mysql is a virtual
> project.
> 
> When a user issues 'xeta install mysql' on a system that has not had
> mysql installed, it will be dealt with like any other virtual
> dependency -- depending on user configuration, Xeta might prompt the
> user to select one between the tree; or present the three options and
> exit with an error; or select a tree-specified default; etc.
> 
> When a user issues 'xeta update mysql' on a system that has had mysql
> installed, it will update to the newest in the version-branch installed.
> 
> Version constraints apply to virtual projects as well; if a package
> specifies '[database server] mysql::lib ge 5.0', the version
> constraint reduces the choices to only mysql-5.0.
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFAEk+sv+6a/MPcjnERAgOZAJwI0CYR0HXFMsMUHpCeCfGhSru9CACfTrT/
> UU6eHuqvfmrPYGRNFkFuetM=
> =K2/j
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> zynaut mailing list
> [email protected]
> http://lists.zynot.org/mailman/listinfo/zynaut