[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Two proposals for a better Lenny (testing related).



Qua, 2007-06-13 às 15:00 -0700, Russ Allbery escreveu:
> Luis Matos <gass@otiliamatos.ath.cx> writes:
> 
> > having a working system *with* only debian *oficial* packages and then
> > after an upgrade that system stops working properly, i call it a
> > regression ...
> 
> If you're using non-free drivers, the first part of your sentence above
> doesn't apply.

I agree ... so what about the linux-modules-contrib-2.6 source package?

> Usually, however, those non-free drivers that are built for each kernel
> get built before the new kernel migrates to testing, but given that those
> builds can't be handled by the general mechanism for building add-on
> modules, I don't think the currency of those builds can be guaranteed.

agreed.
> 
> My recommendation is to always use module-assistant for all non-free
> drivers that you want to use.  That way, if there is a build in non-free,
> you can be pleasantly surprised, but your normal method will always work.

i don't think that this is useful in a debian way. That is equal to tell
the maintainer to stop his work.

> 
> Many non-free drivers (and some free drivers, for that matter) are never
> automatically built at the moment, although with the new mechanism for
> building modules in main, hopefully that number will drop over time for
> the free ones.

i hope so.
i want to tell a couple of things:
 1. My critic goes for the automatic passage of packages that make other
packages (already available in testing) uninstallable or conflictive. In
these 2 sets are packages that have reverse depends and, for example,
the kernel.
 2. You, like other, confirm this situation, but for some reason, you
just don't explicit agree with it.
 3. My main objective is to turn testing an *REAL* alternative for
stable. I've used testing (now i am running stable). It's quite stable,
but some upgrades break stuff. This breakage should not happen and
packages that cause breakage should not pass into testing.
 4. Making testing more visible as a bleeding edge (+/-) *stable*
distribution would be a nice thing and people would appreciate. Making
snapshots (full cd sets called previews, for one example) would make it
visible and useful. Users with testing (commonly home or power users)
can see it's system evolute, while it remains stable, usable and
bleeding edge (stability would be preferred over bleeding edge).
 5. CUT is *THE* option for testing that would permit this.

just my thoughts.

Luis Matos
> 
> -- 
> Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
> 
> 



Reply to: