On Sat, 9 Aug 2003, Per [iso-8859-1] �yvind Karlsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Saturday 09 August 2003 21:00, Austin wrote: > > > > It would be an amazing feature. The only two tricky parts would be: > > 1. making it 'intelligent' enough to only upgrade the necessary > > libraries, and not break other packages depending on them
Well, the logic would be to only upgrade to a package provided by a "source" medium if there was none provided by a "binary" medium. > > 2. extra work for already over-taxed packagers to keep things > > rebuilding on older/stable versions Well, one could always make the pre-condition that bug reports on source packages can only be accpeted with a patch to fix the problem, without affecting any other releases (ie place the responsibility on the user when using source packages, since they basically have it now anyway). > I cannot see how this would solve the problem with packages unable to build on > older releases, you still have to satisfy those new dependencies, Which would be resolved for you, by upgrading or installing a new depdency. > maybe you > could try to cut stuff down a little, and only compile in features you want > yourself, not linking against libraries you don't need etc... but for what? Well, I think it might be an idea to consider making it so a user can choose once which features he wants (ie someone may want no ldap depedencies ever). But again, it would be optional, and the user wanting this would supply the necessary patch. > also think of the nightmare when it comes to bug reporting/solving if > everyone > were to use different compile options, flags etc. The other condition for bug reports on source packages could be that they have been tested at standard optimisations. > and if this is for making it easier for user joe to use new versions of > packages on an old release, I just don't think he's interested in spending a > day compiling everything needed for the latest kde.. If he was going to do it anyway, and it only takes 10 minutes of *his* time (and 47 hours 50 minutes for his computer over the weekend while he is away doing something else), we've easily saved a lot of time. The one issue is that it may encourage packagers to think more carefully (and read docs in packages) when setting buildrequires, but I think that is a good thing. IMHO: -this would be very useful to a lot of people on this list (ie not just a gimmick) -it could be a lot of work -if policies were set correctly, maintainers would only need apply changes submitted to them. Oh yes, there is onemore complication, figuring out which SRPM builds a package BuildRequire'd by another SRPM ... Time to get to know perl::URPM I fear ... Regards, Buchan -- |----------------Registered Linux User #182071-----------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 ****************************************************************** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. ******************************************************************
