On Thu Oct 02, 2003 at 09:00:57AM +0200, Luca Berra wrote: > >Some, not all. If packages were done to handle old versions while working > >with the current, this would be a different story. But this can be very > >difficult... I have some specs that can rebuild on older distribs and some > >of them are *very* convoluted. Take my qmail packages for example... > >before > some of the pain could be eased if we had an updated rpm package for > older versions (supported older versions, i mean, not 7.2) that levels > the packaging macros to 9.2
Shouldn't difficult. We've put out rpm macro updates before. And, FYI, the oldest version we support now is 9.0 (8.2 went EOL two days ago). The exception to that is MNF which is based on 8.2. Of course, the macros are just part of it. If a spec is tuned, say, for a new version of cyrus-sasl in cooker, the maintainer has to be aware that what was required for the old version has to then be put in as conditionals. Not all maintainers do this. > >>I don't believe there is anyone enjoying having to mantain 4 different > >>packages of the same software when one would suffice. > > > >Probably not. But if you, as a contributor, have a cooker machine and > >compile on cooker, how can you possibly know if your package, despite > >having > >conditional build macros, will work with an older distrib if you don't take > >the time to build and test on that old platform? So you *do* need to > >maintain it in such a manner otherwise you're just pumping out stuff that > >pretends to work on old distribs and you really don't have a clue if it > >does > >or not. > Yes, i do need to test and to maintain a package in such a manner. > during last development cycle i had a 9.0 mail/web-server, a 9.1 laptop and > a cooker box at home, and i usually tested stuff there. But that was > from the same package, not different specs with different patches for > each release. > > The problem for me will be when i upgrade the server to 9.2 :( > > Btw, some packages in contrib are very well packaged and maintained, > some are playground for new features and some just suck, maybe splitting > contrib in sections based on package quality and starting to maintain > updates only for the stable part of contrib could be a start. > (if this has already been discussed just shoot at me and i will shut up) > Would other contributors be adverse on taking the commitment of > maintaining 'stable' packages for 'supported' version of mandrake (that > should be 18 months or 3 releases IIRC)? I don't think splitting contribs further is the answer... I really don't. How is that any different from the current situation? Now we have main and contribs... you want to turn that into main, contribs-stable, contribs-possibly-works, and contribs-junk? =) -- MandrakeSoft Security; http://www.mandrakesecure.net/ Online Security Resource Book; http://linsec.ca/ "lynx -source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp00000.pgp
Description: PGP signature
