Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Mike Frysinger <vapier@g.o>
Subject: Re: Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Date: Sun, 2 Oct 2011 16:11:02 -0400
On Sunday, October 02, 2011 16:00:30 Chí-Thanh Christopher Nguyễn wrote:
> I agree that a downgrade is a bit inconvenient for users. But if another
> package is built later with DEPEND on newer linux-headers or emerge
> --deep option, then it will get upgraded again. As no package runtime
> depends on it, the system will not function any worse with old
> linux-headers.

the system is functioning wrongly because you're forcing users to needlessly 
upgrade/downgrade packages.  in addition, packages in the tree aren't the only 
things to be considered.  if the user is building code that works fine against 
the latest stable, but your package forced it to downgrade, they might no 
longer build correctly.

> I propose that if linux-headers maintainers want to make downgrades
> "illegal" (as the new summary to bug 361181 suggests) or restricted in
> some way, they do so in policy or code.

this has nothing to do with linux-headers.  causing *any* other package to go 
through upgrade/downgrade cycles is bad.  as Samuli said, this is pure common 
sense.  i'm not sure why we need to explicitly spell this out.

> Not by surprise treecleaning of packages.

as you were already shown, this wasn't really a surprise.  it went through the 
normal announce process, albeit not the normal 30 day grace period.

> > further, when the newer version gets stabilized and then the older ones
> > dropped, what then ?  your package is broken.
> 
> Yes, when the older one is dropped _that_ would be reason for
> masking+removal. However I have not seen any plans of doing so. Actually
> the current amd64 stable 2.6 versions are 35, 26 and 10 months old
> respectively, I wouldn't expect that to happen any time soon.

sorry, but that's irrelevant.  the lack of tree-cleaning is more due to 
missing automatic generation of ChangeLog files.  but if this is going to be a 
sticking point for you, i can simply clean the tree as soon as we get newer 
stable versions.

> > skipping 30 days is a bit premature, but re-adding it at this point
> > doesn't make sense.  fix it and re-add it, or don't re-add it at all.
> 
> That seems to be the only sensible solution at this point. I will
> probably find time next week or so to create and test a new ebuild.

sounds great
-mike
Attachment:
signature.asc (This is a digitally signed message part.)
Replies:
Re: Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
-- Chí-Thanh Christopher Nguyễn
References:
Re: Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
-- Mike Frysinger
Re: Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
-- Chí-Thanh Christopher Nguyễn
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Next by thread:
Re: Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Previous by date:
Re: Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Next by date:
Re: Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.