[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Samuli Suominen]

On 10/01/2011 08:02 PM, Chi-Thanh Christopher Nguyen (chithanh) wrote:
> chithanh    11/10/01 17:02:59
> 
>   Added:                metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
>   Log:
>   Bring back qutecom.

Bringing back version of qutecom, that is forcing downgrade on
linux-headers, when >= 2.6.38 is being stabilized is completely
unacceptable.

It is NOT gentoo-x86 compatible package in it's current form.

>   
>   (Portage version: 2.2.0_alpha53/cvs/Linux x86_64)
> 
> Revision  Changes    Path
> 1.3                  net-im/qutecom/metadata.xml
> 
> file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-im/qutecom/metadata.xml?rev=1.3&view=markup
> plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-im/qutecom/metadata.xml?rev=1.3&content-type=text/plain
> diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-im/qutecom/metadata.xml?r1=1.2&r2=1.3
> 
> 
> 
> 
> 1.9                  net-im/qutecom/ChangeLog
> 
> file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-im/qutecom/ChangeLog?rev=1.9&view=markup
> plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-im/qutecom/ChangeLog?rev=1.9&content-type=text/plain
> diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-im/qutecom/ChangeLog?r1=1.8&r2=1.9
> 
> 
> 
> 
> 1.5                  net-im/qutecom/qutecom-2.2_p20110210.ebuild
> 
> file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-im/qutecom/qutecom-2.2_p20110210.ebuild?rev=1.5&view=markup
> plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-im/qutecom/qutecom-2.2_p20110210.ebuild?rev=1.5&content-type=text/plain
> diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-im/qutecom/qutecom-2.2_p20110210.ebuild?r1=1.4&r2=1.5
> 
> 
> 
> 
> 

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/01/11 19:29, Samuli Suominen wrote:
> On 10/01/2011 08:02 PM, Chi-Thanh Christopher Nguyen (chithanh)
> wrote:
>> chithanh    11/10/01 17:02:59
>> 
>> Added:                metadata.xml ChangeLog
>> qutecom-2.2_p20110210.ebuild Log: Bring back qutecom.
> 
> Bringing back version of qutecom, that is forcing downgrade on 
> linux-headers, when >= 2.6.38 is being stabilized is completely 
> unacceptable.
> 
> It is NOT gentoo-x86 compatible package in it's current form.
> 
>> 
This is fixed upstream[1]. Please bump and remove the existing ebuild
since as Samuli said it is a no-go in its current form.

[1]:http://trac.qutecom.org/ticket/287

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOh2ATAAoJEPqDWhW0r/LCamQQAJEc9lKKXD3OVv0mkR3JyQKD
1b2Tt2RMS8RiG3t00Ak3THxcmtHEg0FtzAJj3i7z6XPAOu5BFC42rmgL2/ubtsiL
a2b8ktuPQQUYOrjI83sMRq9A+W0aJH5MAcyIoRmy0uPBG611wo5u3XRGz5yaReAP
DiOIODbIFZ4jODyiBp3rP8bEijW6LLVALsE4v7Ni70DTwLLIpya3wKOC5k7T6ZLn
dxc6z9IDJpvL4ymDR+HszFuRUkUpg0CfEwEu42+QIfPUQ1ZIPjPst6zsdFCWCvo8
2N4p4vhOsdf4s0mRcfBbDKUrzc8DPhnk2eiqN+fwU/M7kjQ87WFJAX/yT5sW1/n4
Ud0xA0pqSIYhVZOkGG/KjuQAWy1c/qyvkNzCV2zijjiVFEIsca7s51HpmfjzBgQV
U+mL5U2Dq38Vmx/28QsszhpbphMai8kh4edqMogjq5eL3kytrrSphhwEo0xIe0bz
qahpnm4tcRjsXPXAii1oEMdXNdNpxsIee+9z1ATiV5LAcph1px0vS2m4/0tbkZNR
O45eEdDr8OQGydXwcPi4f4jpLeafpGRTBmXvZo4VJTF75TuxpHp7UDfKWciHTQvw
zcvnOivhlMNaJSRXMRTd4ZwnWcENWpYOMXvm3lqOsWs7sfPxcbyFFLY2gAIFXt5F
OFDNeW03k3j6GACnMT9G
=3haF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Chí-Thanh Christopher Nguyễn]

Samuli Suominen schrieb:
> On 10/01/2011 08:02 PM, Chi-Thanh Christopher Nguyen (chithanh) wrote:
>> chithanh    11/10/01 17:02:59
>>
>>   Added:                metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
>>   Log:
>>   Bring back qutecom.
> 
> Bringing back version of qutecom, that is forcing downgrade on
> linux-headers, when >= 2.6.38 is being stabilized is completely
> unacceptable.

Please point to existing authoritative documentation which says that
downgrades are unacceptable.

> It is NOT gentoo-x86 compatible package in it's current form.

It sets correct dependency on an existing ebuild in tree. The dependency
is only build time, users can upgrade linux-headers again afterwards.
The application itself is v4l2 compatible.

What I am a bit unhappy about is that the package was masked and removed
while I was away. Even bypassing the usual 30 days and no last rite
announcement was sent to -dev.

Bug 361181 is certainly on my TODO list, just not very high up to now.
If you think that there is some urgency in getting rid of the package,
please do explain so in advance.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Samuli Suominen]

On 10/02/2011 02:44 AM, Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
>> On 10/01/2011 08:02 PM, Chi-Thanh Christopher Nguyen (chithanh) wrote:
>>> chithanh    11/10/01 17:02:59
>>>
>>>   Added:                metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
>>>   Log:
>>>   Bring back qutecom.
>>
>> Bringing back version of qutecom, that is forcing downgrade on
>> linux-headers, when >= 2.6.38 is being stabilized is completely
>> unacceptable.
> 
> Please point to existing authoritative documentation which says that
> downgrades are unacceptable.
> 
>> It is NOT gentoo-x86 compatible package in it's current form.
> 
> It sets correct dependency on an existing ebuild in tree. The dependency
> is only build time, users can upgrade linux-headers again afterwards.
> The application itself is v4l2 compatible.

common sense...

http://bugs.gentoo.org/show_bug.cgi?id=311241#c2
http://bugs.gentoo.org/show_bug.cgi?id=311241#c5

linux-headers -> glibc.  no package should force downgrade on
linux-headers, risking glibc building against older version than
KEYWORDS visibility would allow.

> What I am a bit unhappy about is that the package was masked and removed
> while I was away. Even bypassing the usual 30 days and no last rite
> announcement was sent to -dev.

http://archives.gentoo.org/gentoo-dev/msg_5e6d8403c90549d8caf4f27f0d14f01f.xml

> Bug 361181 is certainly on my TODO list, just not very high up to now.
> If you think that there is some urgency in getting rid of the package,
> please do explain so in advance.

The time ran out with opening of http://bugs.gentoo.org/384733 for
linux-headers reverse deps to be tracked stable.

I've removed qutecom for you again.

- Samuli

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Chí-Thanh Christopher Nguyễn]

Samuli Suominen schrieb:
>> Please point to existing authoritative documentation which says that
>> downgrades are unacceptable.
>>
>>> It is NOT gentoo-x86 compatible package in it's current form.
>>
>> It sets correct dependency on an existing ebuild in tree. The dependency
>> is only build time, users can upgrade linux-headers again afterwards.
>> The application itself is v4l2 compatible.
> 
> common sense...
>
> http://bugs.gentoo.org/show_bug.cgi?id=311241#c2
> http://bugs.gentoo.org/show_bug.cgi?id=311241#c5

linux-headers is not a library, it is strictly a build time dependency
for all packages which I am aware of.

> linux-headers -> glibc.  no package should force downgrade on
> linux-headers, risking glibc building against older version than
> KEYWORDS visibility would allow.

No idea where the risk in that is documented. If there is a danger in
building new glibc against old linux-headers, it would surely deserve a
notice somewhere?

>> What I am a bit unhappy about is that the package was masked and removed
>> while I was away. Even bypassing the usual 30 days and no last rite
>> announcement was sent to -dev.
> 
> http://archives.gentoo.org/gentoo-dev/msg_5e6d8403c90549d8caf4f27f0d14f01f.xml
> 

Ok sorry, I missed that mail for some reason. But 30 days were still
bypassed.

> The time ran out with opening of http://bugs.gentoo.org/384733 for
> linux-headers reverse deps to be tracked stable.
> 
> I've removed qutecom for you again.

Please put it back in tree. You have my consent to remove it on 13
October (when the 30 days are over) and I have not fixed it yet.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1580 bytes --]

On Sunday, October 02, 2011 08:58:19 Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
> >> Please point to existing authoritative documentation which says that
> >> downgrades are unacceptable.
> >> 
> >>> It is NOT gentoo-x86 compatible package in it's current form.
> >> 
> >> It sets correct dependency on an existing ebuild in tree. The dependency
> >> is only build time, users can upgrade linux-headers again afterwards.
> >> The application itself is v4l2 compatible.
> > 
> > common sense...
> > 
> > http://bugs.gentoo.org/show_bug.cgi?id=311241#c2
> > http://bugs.gentoo.org/show_bug.cgi?id=311241#c5
> 
> linux-headers is not a library, it is strictly a build time dependency
> for all packages which I am aware of.

forcing downgrades of random packages is extremely poor behavior.  it doesn't 
matter if it's DEPEND or RDEPEND behavior.  if your one package is the last 
thing to get installed, then you leave the system in a poor state.

further, when the newer version gets stabilized and then the older ones 
dropped, what then ?  your package is broken.

> > The time ran out with opening of http://bugs.gentoo.org/384733 for
> > linux-headers reverse deps to be tracked stable.
> > 
> > I've removed qutecom for you again.
> 
> Please put it back in tree. You have my consent to remove it on 13
> October (when the 30 days are over) and I have not fixed it yet.

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.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Chí-Thanh Christopher Nguyễn]

Mike Frysinger schrieb:
> On Sunday, October 02, 2011 08:58:19 Chí-Thanh Christopher Nguyễn wrote:
>> Samuli Suominen schrieb:
>>>> Please point to existing authoritative documentation which says that
>>>> downgrades are unacceptable.
>>>>
>>>>> It is NOT gentoo-x86 compatible package in it's current form.
>>>>
>>>> It sets correct dependency on an existing ebuild in tree. The dependency
>>>> is only build time, users can upgrade linux-headers again afterwards.
>>>> The application itself is v4l2 compatible.
>>>
>>> common sense...
>>>
>>> http://bugs.gentoo.org/show_bug.cgi?id=311241#c2
>>> http://bugs.gentoo.org/show_bug.cgi?id=311241#c5
>>
>> linux-headers is not a library, it is strictly a build time dependency
>> for all packages which I am aware of.
> 
> forcing downgrades of random packages is extremely poor behavior.  it doesn't 
> matter if it's DEPEND or RDEPEND behavior.  if your one package is the last 
> thing to get installed, then you leave the system in a poor state.

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.

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. Not by surprise treecleaning of
packages.

> 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.

> 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.

Though I must say that allowing this clear policy violation to stand
while I don't see any policy violation in my ebuild leaves a bad impression.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2320 bytes --]

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Chí-Thanh Christopher Nguyễn]

Mike Frysinger schrieb:
> 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.

Then the code is broken that is built outside portage and does not
function correctly with old linux-headers without doing any kind of
version check.

And again, downgrade of dependencies it is not against any rule which
would justify mask and removal.

Another example from the X.org packages, installing the proprietary
ATI/NVidia drivers will cause downgrades for xorg-server on ~arch
systems. Nobody in his right mind is proposing to treeclean them because
of this.

>> 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.

The whole process was a surprise to me because the masking and
treecleaning happened while I was on 20 days of devaway. I leave the
away message for a day more in case anyone wants to verify.

And it was a surprise treecleaning because the mask and policy said 30
days, but the removal happened before the 30 days were over.

The second time the package was removed was even without mask or
announcement.

>>> 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.

If the old versions and reverse dependencies are dropped in accordance
with
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap7
then I won't complain.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Samuli Suominen]

On 10/02/2011 11:40 PM, Chí-Thanh Christopher Nguyễn wrote:
> Mike Frysinger schrieb:
>> 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.
> 
> Then the code is broken that is built outside portage and does not
> function correctly with old linux-headers without doing any kind of
> version check.

That too, no doubt about it, but that doesn't invalidate what Mike
already said.

> And again, downgrade of dependencies it is not against any rule which
> would justify mask and removal.
> 
> Another example from the X.org packages, installing the proprietary
> ATI/NVidia drivers will cause downgrades for xorg-server on ~arch
> systems. Nobody in his right mind is proposing to treeclean them because
> of this.
> 

The new xorg-servers could get package.masked until these major drivers
are available.
Albeit, I'm not intrested in pursuing this since with separate
xorg-server package, it's the drivers that need rebuilding against it,
and the VIDEO_CARDS="" setting is keeping it in certain version until
the VIDEO_CARDS="" setting is satisfied.

Poor example to make a case.

>>>> 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.
> 
> If the old versions and reverse dependencies are dropped in accordance
> with
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap7
> then I won't complain.

The intresting part of that document is "You should also not cause an
unnecessary downgrade for any "~arch" when ..." which also applies to
setting dependencies just as well.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Chí-Thanh Christopher Nguyễn]

Samuli Suominen schrieb:

>> And again, downgrade of dependencies it is not against any rule which
>> would justify mask and removal.
>>
>> Another example from the X.org packages, installing the proprietary
>> ATI/NVidia drivers will cause downgrades for xorg-server on ~arch
>> systems. Nobody in his right mind is proposing to treeclean them because
>> of this.
>>
> 
> The new xorg-servers could get package.masked until these major drivers
> are available.
> Albeit, I'm not intrested in pursuing this since with separate
> xorg-server package, it's the drivers that need rebuilding against it,
> and the VIDEO_CARDS="" setting is keeping it in certain version until
> the VIDEO_CARDS="" setting is satisfied.
> 
> Poor example to make a case.

VIDEO_CARDS is just for user convenience. run "emerge nvidia-drivers" on
any system with xorg-server-1.11 installed and it will downgrade, no
matter what VIDEO_CARDS is set to.

> The intresting part of that document is "You should also not cause an
> unnecessary downgrade for any "~arch" when ..." which also applies to
> setting dependencies just as well.

The downgrade is necessary to avoid user-visible breakage.
And the wording clearly does only apply to package removals.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Samuli Suominen]

On 10/03/2011 12:37 AM, Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
> 
>>> And again, downgrade of dependencies it is not against any rule which
>>> would justify mask and removal.
>>>
>>> Another example from the X.org packages, installing the proprietary
>>> ATI/NVidia drivers will cause downgrades for xorg-server on ~arch
>>> systems. Nobody in his right mind is proposing to treeclean them because
>>> of this.
>>>
>>
>> The new xorg-servers could get package.masked until these major drivers
>> are available.
>> Albeit, I'm not intrested in pursuing this since with separate
>> xorg-server package, it's the drivers that need rebuilding against it,
>> and the VIDEO_CARDS="" setting is keeping it in certain version until
>> the VIDEO_CARDS="" setting is satisfied.
>>
>> Poor example to make a case.
> 
> VIDEO_CARDS is just for user convenience. run "emerge nvidia-drivers" on
> any system with xorg-server-1.11 installed and it will downgrade, no
> matter what VIDEO_CARDS is set to.

And your point is? The drivers will need to be rebuilt everytime the
xorg-server version changes. This does not come as a suprise, the
.ebuild should print a message about rebuilding them. If it doesn't,
then the .ebuild should get fixed.
Leaving this particular case for X.org maintainers to decide sounds fine
to me, given the relaxing factors.

> 
>> The intresting part of that document is "You should also not cause an
>> unnecessary downgrade for any "~arch" when ..." which also applies to
>> setting dependencies just as well.
> 
> The downgrade is necessary to avoid user-visible breakage.

Avoiding one in non-system critical package (like qutecom), but
introducing multiple new scenarios in what-could-be system-critical
packages.

> And the wording clearly does only apply to package removals.

The fact that the *common sense* snippet was inserted in this document,
but isn't documented else where... doesn't make it any less true.

- Samuli

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Chí-Thanh Christopher Nguyễn]

Samuli Suominen schrieb:
>>> Poor example to make a case.
>>
>> VIDEO_CARDS is just for user convenience. run "emerge nvidia-drivers" on
>> any system with xorg-server-1.11 installed and it will downgrade, no
>> matter what VIDEO_CARDS is set to.
> 
> And your point is?

My point is that packages can cause downgrades through "<" dependencies.
There is no rule against it.

Maybe going through upgrade/downgrade cycles is inconvenient for some
users, or downgrades affect a package that you are particularly
interested in. That still doesn't make it justified to remove a package
against the maintainer's wishes. And certainly not to remove it twice
cutting short the required treecleaning process, the second time _after_
I have stated to be willing to fix the bug and challenging you to point
out the authoritative documentation my ebuild was in violation of.

>> And the wording clearly does only apply to package removals.
> 
> The fact that the *common sense* snippet was inserted in this document,
> but isn't documented else where... doesn't make it any less true.

It may be obvious to you, but it certainly is not obvious to me why
linux-headers downgrade is so bad. If vapier's unsupported out-of-tree
software fails to build against old linux-headers, then he has to make
sure to have the correct version installed before proceeding. Blaming
that on qutecom is far-fetched IMO.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[malc]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

Really... it took me less time to chuck the new-videodev.patch from [1] into
src_prepare() and compile-test than it did to read the noise in this
thread... :)

HTH,
malc.

[1] http://patch-tracker.debian.org/package/qutecom/2.2.1+dfsg1-2

[-- Attachment #2: Type: text/html, Size: 383 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Samuli Suominen]

On 10/03/2011 02:45 AM, malc wrote:
> Really... it took me less time to chuck the new-videodev.patch from [1]
> into src_prepare() and compile-test than it did to read the noise in
> this thread... :)
> 
> HTH,
> malc.
> 
> [1] http://patch-tracker.debian.org/package/qutecom/2.2.1+dfsg1-2
> 

I have seen this patch, but I'm not convinced it's correct as it doesn't
rename (prefix) any of the functions with v4l1_

Thinking of v4l1_open, v4l1_close, and the basics here

So I suspect the Debian maintainer just threw that in, without runtime
testing the application. Ready to be proofen wrong.

- Samuli

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

On 00:31 Mon 03 Oct     , Chí-Thanh Christopher Nguyễn wrote:
> It may be obvious to you, but it certainly is not obvious to me why
> linux-headers downgrade is so bad. If vapier's unsupported out-of-tree
> software fails to build against old linux-headers, then he has to make
> sure to have the correct version installed before proceeding. Blaming
> that on qutecom is far-fetched IMO.

There's like a million packages that use features in linux-headers, so 
it's not a isolated effect as with xorg-server.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Graham Murray]

Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> writes:

> My point is that packages can cause downgrades through "<" dependencies.
> There is no rule against it.

Nearly all of which prevent the upgrade of the dependent package rather
forcing the downgrade of an already installed package.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 3083 bytes --]

On Sunday 02 October 2011 16:40:18 Chí-Thanh Christopher Nguyễn wrote:
> Another example from the X.org packages, installing the proprietary
> ATI/NVidia drivers will cause downgrades for xorg-server on ~arch
> systems. Nobody in his right mind is proposing to treeclean them because
> of this.

yes, this does cause issues for some, but i think we're willing to make 
exceptions when they're justified -- life isn't black & white after all.  the 
user base is fairly large enough to accept the downsides here.  it's also 
proprietary, so we don't have nearly as much chance of getting it fixed.  
conversely, i'd put forth that qutecom does not have a user base size to 
justify causing misbehavior (too bad we don't have installed package 
statistics to provide some data here), and the fact that it's open source 
means it should get fixed or get punted.

otherwise, Rich summed up things nicely in his later post.

> >> 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.
> 
> The whole process was a surprise to me because the masking and
> treecleaning happened while I was on 20 days of devaway. I leave the
> away message for a day more in case anyone wants to verify.
> 
> And it was a surprise treecleaning because the mask and policy said 30
> days, but the removal happened before the 30 days were over.

the use of "surprise" can be flexed here.  yes, you were surprised it was 
punted, but that doesn't make it a "surprise treecleaning" to the larger 
community.  the package has had an open bug for a while, was announced that it 
was going to be removed, and was cleaned ~17 days after the announcement.

> The second time the package was removed was even without mask or
> announcement.

well, it shouldn't have been re-added in the first place

> >>> 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.
> 
> If the old versions and reverse dependencies are dropped in accordance
> with
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#do
> c_chap7 then I won't complain.

i would not consider broken packages (i.e. qutecom) in the tree as basis for 
retaining the old versions of linux-headers.  your package is already broken, 
and removing the linux-headers would break that depgraph.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Chí-Thanh Christopher Nguyễn]

Mike Frysinger schrieb:

> otherwise, Rich summed up things nicely in his later post.

If you mean that common sense thing: if there is disagreement about it,
then it is obviously not common.

>> The second time the package was removed was even without mask or
>> announcement.
> well, it shouldn't have been re-added in the first place

Why not? Nothing in the Gentoo documentation forbids adding an ebuild
which downgrades linux-headers or any other package.

And it is not that I dumped the package to rot there. In my email to
-devel I said that I was going to address the problem that suddenly
became so urgent.

> i would not consider broken packages (i.e. qutecom) in the tree as basis for 
> retaining the old versions of linux-headers.

At no point I even suggested that old linux-headers versions be retained
for qutecom.

>  your package is already broken, 
> and removing the linux-headers would break that depgraph.

The removed qutecom ebuild was not broken at any time. It builds and
runs fine with the packages in portage. It may trigger a linux-headers
downgrade, but if that really causes breakage in other packages (and I
am not convinced, as you gave only vague arguments, and a Google search
didn't turn up anything) then it could be reason for masking. But not
reason for removal.

Only after all <linux-headers-2.6.38 versions are removed, then it is
indeed uninstallable and needs to be fixed or treecleaned.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2517 bytes --]

On Wednesday 12 October 2011 17:42:47 Chí-Thanh Christopher Nguyễn wrote:
> Mike Frysinger schrieb:
> > otherwise, Rich summed up things nicely in his later post.
> 
> If you mean that common sense thing: if there is disagreement about it,
> then it is obviously not common.

you're mixing "common" with "absolute".  so far, you're the only one who seems 
to think that this behavior is generally acceptable.

> >> The second time the package was removed was even without mask or
> >> announcement.
> > 
> > well, it shouldn't have been re-added in the first place
> 
> Why not? Nothing in the Gentoo documentation forbids adding an ebuild
> which downgrades linux-headers or any other package.

there is plenty of stupid stuff the documentation doesn't forbid.  again, refer 
to Rich's post.

qutecom is hardly an important package that it gets an exception.  i'm sure 
all 3 Gentoo users were saddened by its demise.

> And it is not that I dumped the package to rot there. In my email to
> -devel I said that I was going to address the problem that suddenly
> became so urgent.

it doesn't matter if you intended on getting the issues fixed.  the issue 
shouldn't have been reintroduced in the first place.  nothing in this path 
necessitated adding bad packages back to the tree.

> >  your package is already broken,
> > and removing the linux-headers would break that depgraph.
> 
> The removed qutecom ebuild was not broken at any time.

by splitting my reply, you changed the meaning.  having qutecom in the tree 
with a depend on versions that i'm now removing breaks the depgraph.

> runs fine with the packages in portage. It may trigger a linux-headers
> downgrade, but if that really causes breakage in other packages (and I
> am not convinced, as you gave only vague arguments, and a Google search
> didn't turn up anything)

i provided a hypothetical that is not unreasonable.  if google could look up 
hypotheticals, then it's probably self-aware.

> then it could be reason for masking. But not reason for removal.

we don't generally keep masked things in the tree.  it's broken, it gets 
masked, then it gets removed.  this isn't complicated.

> Only after all <linux-headers-2.6.38 versions are removed, then it is
> indeed uninstallable and needs to be fixed or treecleaned.

the existence of other versions is irrelevant.  your pkg is broken and needs 
to be fixed now regardless of what happens to old linux-headers versions.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Chí-Thanh Christopher Nguyễn]

Mike Frysinger schrieb:
>> The removed qutecom ebuild was not broken at any time.
> 
> by splitting my reply, you changed the meaning.  having qutecom in the tree 
> with a depend on versions that i'm now removing breaks the depgraph.

The depgraph is broken after the old versions are removed, not before.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Samuli Suominen]

On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote:
> Mike Frysinger schrieb:
>>> The removed qutecom ebuild was not broken at any time.
>>
>> by splitting my reply, you changed the meaning.  having qutecom in the tree 
>> with a depend on versions that i'm now removing breaks the depgraph.
> 
> The depgraph is broken after the old versions are removed, not before.

I'm not sure if you should have gentoo-x86 access anymore... This is scary.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Matt Turner]

On Wed, Oct 12, 2011 at 7:58 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote:
>> Mike Frysinger schrieb:
>>>> The removed qutecom ebuild was not broken at any time.
>>>
>>> by splitting my reply, you changed the meaning.  having qutecom in the tree
>>> with a depend on versions that i'm now removing breaks the depgraph.
>>
>> The depgraph is broken after the old versions are removed, not before.
>
> I'm not sure if you should have gentoo-x86 access anymore... This is scary.

Come on. That's ridiculous, and nothing but trolling. Don't do that.

Like in the pngcrush thread, miscommunications all around.

Matt

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Samuli Suominen]

On 10/13/2011 03:10 AM, Matt Turner wrote:
> On Wed, Oct 12, 2011 at 7:58 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>> On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote:
>>> Mike Frysinger schrieb:
>>>>> The removed qutecom ebuild was not broken at any time.
>>>>
>>>> by splitting my reply, you changed the meaning.  having qutecom in the tree
>>>> with a depend on versions that i'm now removing breaks the depgraph.
>>>
>>> The depgraph is broken after the old versions are removed, not before.
>>
>> I'm not sure if you should have gentoo-x86 access anymore... This is scary.
> 
> Come on. That's ridiculous, and nothing but trolling. Don't do that.
> 
> Like in the pngcrush thread, miscommunications all around.
> 
> Matt
> 

(see my reply to Mike. I admit that came out way too blunt. sorry
Chi-Thanh, Matt.)

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 600 bytes --]

On Wednesday 12 October 2011 19:58:31 Samuli Suominen wrote:
> On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote:
> > Mike Frysinger schrieb:
> >>> The removed qutecom ebuild was not broken at any time.
> >> 
> >> by splitting my reply, you changed the meaning.  having qutecom in the
> >> tree with a depend on versions that i'm now removing breaks the
> >> depgraph.
> > 
> > The depgraph is broken after the old versions are removed, not before.
> 
> I'm not sure if you should have gentoo-x86 access anymore... This is scary.

this isn't helping the conversation
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Samuli Suominen]

On 10/13/2011 03:19 AM, Mike Frysinger wrote:
> On Wednesday 12 October 2011 19:58:31 Samuli Suominen wrote:
>> On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote:
>>> Mike Frysinger schrieb:
>>>>> The removed qutecom ebuild was not broken at any time.
>>>>
>>>> by splitting my reply, you changed the meaning.  having qutecom in the
>>>> tree with a depend on versions that i'm now removing breaks the
>>>> depgraph.
>>>
>>> The depgraph is broken after the old versions are removed, not before.
>>
>> I'm not sure if you should have gentoo-x86 access anymore... This is scary.
> 
> this isn't helping the conversation
> -mike

you're right. sorry. that came out too harsh. lets rephrase this as:

"This /topic should be in the end-quiz, and mentioned in the mentoring
guide to cover basis as part of the KEYWORDS visibility handling."

- Samuli

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Chí-Thanh Christopher Nguyễn]

Samuli Suominen schrieb:
> you're right. sorry. that came out too harsh. lets rephrase this as:

No offense taken :)

> "This /topic should be in the end-quiz, and mentioned in the mentoring
> guide to cover basis as part of the KEYWORDS visibility handling."

This is something that I have been asking for all the time. If you think
that what qutecom did should be illegal in Gentoo, then disallow it in
policy or code.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Samuli Suominen]

On 10/13/2011 06:09 PM, Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
>> you're right. sorry. that came out too harsh. lets rephrase this as:
> 
> No offense taken :)
> 
>> "This /topic should be in the end-quiz, and mentioned in the mentoring
>> guide to cover basis as part of the KEYWORDS visibility handling."
> 
> This is something that I have been asking for all the time. If you think
> that what qutecom did should be illegal in Gentoo, then disallow it in
> policy or code.

Drop that "should be" act, please.   It looks as if you were still
suggesting it was fine to do what qutecom did...

Merely saying if we had some documentation snippet, or an end-quiz
question for this, QA could more easily/faster revoke access if someone
were to do this intentionally in tree. This could be minor motivation
for me to write such snippet, but it's definately not near top on my TODO.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Rich Freeman]

On Thu, Oct 13, 2011 at 1:45 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> Merely saying if we had some documentation snippet, or an end-quiz
> question for this, QA could more easily/faster revoke access if someone
> were to do this intentionally in tree. This could be minor motivation
> for me to write such snippet, but it's definately not near top on my TODO.

I think that something that is worth an official policy is whether in
fact "<" or "=" dependencies are acceptable, or in general when they
are acceptable.  That isn't to say that we have to enumerate all
possibilities, but there should be guidelines.

I don't think there really is a clear consensus on this.  It is
definitely a can of worms and I don't think black-and-white is the
right approach to take.  While slotting libraries is often an option,
that gets a lot messier when you're talking about things like header
files.

Rich

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

On Thu, 13 Oct 2011 13:52:37 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> While slotting libraries is often an option, that gets a lot messier
> when you're talking about things like header files.

You can make slots mutually blocking if you do it carefully. It does
get a bit horrible without := dependencies though...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Chí-Thanh Christopher Nguyễn]

Samuli Suominen schrieb:
>> This is something that I have been asking for all the time. If you think
>> that what qutecom did should be illegal in Gentoo, then disallow it in
>> policy or code.
> 
> Drop that "should be" act, please.   It looks as if you were still
> suggesting it was fine to do what qutecom did...

Before the package was masked for removal, I was fairly convinced that
it was fine. Then I noticed that you have different opinions.

If "<linux-headers-…" dependencies violate policy, then I would like to
read the authoritative document which describes that policy. If
downgrading linux-headers breaks systems, then I would like to hear
about incidents where this actually happened. My Google-fu is apparently
too weak to find these.

If the policy is not clear on the matter then removal against
maintainer's consent is not justified. If the breakage is only
hypothetical then not even a p.mask is justified IMO (though I
understand that QA can mask packages at their discretion without needing
any reason).


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 441 bytes --]

On Wednesday 12 October 2011 19:27:41 Chí-Thanh Christopher Nguyễn wrote:
> Mike Frysinger schrieb:
> >> The removed qutecom ebuild was not broken at any time.
> > 
> > by splitting my reply, you changed the meaning.  having qutecom in the
> > tree with a depend on versions that i'm now removing breaks the
> > depgraph.
> 
> The depgraph is broken after the old versions are removed, not before.

which is what i said
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Chí-Thanh Christopher Nguyễn]

Mike Frysinger schrieb:
>>> by splitting my reply, you changed the meaning.  having qutecom in the
>>> tree with a depend on versions that i'm now removing breaks the
>>> depgraph.
>> The depgraph is broken after the old versions are removed, not before.
> which is what i said

So qutecom is not broken and needs not be removed as long as
<linux-headers-2.6.38 is in the tree.
Of course any package breaks when you remove its dependencies.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]

On Thu, 13 Oct 2011 12:23:07 +0200
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> So qutecom is not broken and needs not be removed as long as
> <linux-headers-2.6.38 is in the tree.

Dependencies using <, <=, =, ~ or =* are broken, except in certain
special situations inside ||.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Chí-Thanh Christopher Nguyễn]

Ciaran McCreesh schrieb:
> On Thu, 13 Oct 2011 12:23:07 +0200
> Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
>> So qutecom is not broken and needs not be removed as long as
>> <linux-headers-2.6.38 is in the tree.
> Dependencies using <, <=, =, ~ or =* are broken, except in certain
> special situations inside ||.

I don't find that documented anywhere. Besides, a number of packages use
= and ~ not inside ||. Are they all broken? How do you suggest to
address this?


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

On Thu, 13 Oct 2011 14:13:11 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Thu, 13 Oct 2011 12:23:07 +0200
> Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> > So qutecom is not broken and needs not be removed as long as
> > <linux-headers-2.6.38 is in the tree.
> 
> Dependencies using <, <=, =, ~ or =* are broken, except in certain
> special situations inside ||.

So, in your opinion, if we have 'foo' and 'libfoo' which are strictly
version-bound, we can't allow users to install older versions?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Rich Freeman]

On Thu, Oct 13, 2011 at 11:26 AM, Michał Górny <mgorny@gentoo.org> wrote:
> So, in your opinion, if we have 'foo' and 'libfoo' which are strictly
> version-bound, we can't allow users to install older versions?

Obviously the real issue is when libfoo is libpng or openssl or whatever.

It almost makes you wonder if the solution is to do a LOT more
slotting.  Maybe with the right automation slotting could be less
painful to maintain.  Of course, if you take that to the ultimate
extreme you'd just have every package install each file with a hash in
the filename and then have /usr/bin et all be a collection of
symlinks.   And before you know it you're running Plan9.  :)

Rich

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Sebastian Luther]

Am 13.10.2011 15:13, schrieb Ciaran McCreesh:
> On Thu, 13 Oct 2011 12:23:07 +0200
> Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
>> So qutecom is not broken and needs not be removed as long as
>> <linux-headers-2.6.38 is in the tree.
> 
> Dependencies using <, <=, =, ~ or =* are broken, except in certain
> special situations inside ||.
> 

Why exactly are they broken?

Sure, it will force the user to choose between installing this and
having the latest version of the package installed. But I don't see this
being a problem.

As an example I always get this on world updates:

WARNING: One or more updates have been skipped due to a dependency conflict:

dev-python/numpy:0
  (dev-python/numpy-1.6.0::gentoo, ebuild scheduled for merge) conflicts
with
    ~dev-python/numpy-1.5.1 required by
(sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed)

dev-python/pexpect:0
  (dev-python/pexpect-2.4-r1::sage-on-gentoo, ebuild scheduled for
merge) conflicts with
    ~dev-python/pexpect-2.0 required by
(sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed)


Fact is that sci-mathematics/sage can't be made work without those deps.
Fact is that I want this package and couldn't care less if I have the
latest version of these other two packages.

If in turn I cared for the other two packages, then I would have to
remove sage. It's a choice but nothing else.

And before some asks, no portage wouldn't break this dep these days:

# emerge -1u --ignore-default-opts -vtp pexpect

These are the packages that would be merged, in reverse order:
Calculating dependencies... done!
Total: 0 packages, Size of downloads: 0 kB

WARNING: One or more updates have been skipped due to a dependency conflict:
dev-python/pexpect:0
  (dev-python/pexpect-2.4-r1::sage-on-gentoo, ebuild scheduled for
merge) conflicts with
    ~dev-python/pexpect-2.0 required by
(sci-mathematics/sage-notebook-0.8.19-r1::sage-on-gentoo, installed)


Sebastian

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1315 bytes --]

On Thursday 13 October 2011 14:15:54 Sebastian Luther wrote:
> WARNING: One or more updates have been skipped due to a dependency
> conflict:
> 
> dev-python/numpy:0
>   (dev-python/numpy-1.6.0::gentoo, ebuild scheduled for merge) conflicts
> with ~dev-python/numpy-1.5.1 required by
> (sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed)
> 
> dev-python/pexpect:0
>   (dev-python/pexpect-2.4-r1::sage-on-gentoo, ebuild scheduled for
> merge) conflicts with ~dev-python/pexpect-2.0 required by
> (sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed)
> 
> Fact is that sci-mathematics/sage can't be made work without those deps.
> Fact is that I want this package and couldn't care less if I have the
> latest version of these other two packages.
> 
> If in turn I cared for the other two packages, then I would have to
> remove sage. It's a choice but nothing else.

it's a crap choice.  users shouldn't have to select from diff sets of packages 
because some are too broken to work properly.  it's a bug and needs to be 
fixed.  and it shouldn't require twisting of arms to make people fix their 
broken packages.

also, sci-mathematics/sage is a poor example here.  it isn't in the main tree.  
if people want to add poor packages to their overlays, they're free to.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Sebastian Luther]

-------- Original-Nachricht --------
> Datum: Fri, 14 Oct 2011 02:01:00 -0400
> Von: Mike Frysinger <vapier@gentoo.org>
> An: gentoo-dev@lists.gentoo.org
> Betreff: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

> On Thursday 13 October 2011 14:15:54 Sebastian Luther wrote:
> > WARNING: One or more updates have been skipped due to a dependency
> > conflict:
> > 
> > dev-python/numpy:0
> >   (dev-python/numpy-1.6.0::gentoo, ebuild scheduled for merge) conflicts
> > with ~dev-python/numpy-1.5.1 required by
> > (sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed)
> > 
> > dev-python/pexpect:0
> >   (dev-python/pexpect-2.4-r1::sage-on-gentoo, ebuild scheduled for
> > merge) conflicts with ~dev-python/pexpect-2.0 required by
> > (sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed)
> > 
> > Fact is that sci-mathematics/sage can't be made work without those deps.
> > Fact is that I want this package and couldn't care less if I have the
> > latest version of these other two packages.
> > 
> > If in turn I cared for the other two packages, then I would have to
> > remove sage. It's a choice but nothing else.
> 
> it's a crap choice.  users shouldn't have to select from diff sets of
> packages 
> because some are too broken to work properly.  it's a bug and needs to be 
> fixed.

Sure, it would be better if it could be fixed. But that's far out of reach at this point (and maybe forever because of the complexity of this thing).

People already have to do random choices for some packages, where completely unrelated packages block each other because of file collisions.

>  and it shouldn't require twisting of arms to make people fix their
> broken packages.
> 
> also, sci-mathematics/sage is a poor example here.  it isn't in the main
> tree.  

If you want an example from the tree, use geany and geany-plugins.

> if people want to add poor packages to their overlays, they're free to.

There are two different aspects here. Having strange deps may make it look poor for the packager, but this does not mean that the package is poor from a user pov.
After all the primary point of packages being in the tree is be used by the users and not for the packager's fun of maintaining them (even though it helps if it is fun).

I agree that those deps should be avoid if possible, but killing an otherwise working package because of them hurts the user more than it helps.


> -mike

Sebastian
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Alec Warner]

On Thu, Oct 13, 2011 at 11:01 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Thursday 13 October 2011 14:15:54 Sebastian Luther wrote:
>> WARNING: One or more updates have been skipped due to a dependency
>> conflict:
>>
>> dev-python/numpy:0
>>   (dev-python/numpy-1.6.0::gentoo, ebuild scheduled for merge) conflicts
>> with ~dev-python/numpy-1.5.1 required by
>> (sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed)
>>
>> dev-python/pexpect:0
>>   (dev-python/pexpect-2.4-r1::sage-on-gentoo, ebuild scheduled for
>> merge) conflicts with ~dev-python/pexpect-2.0 required by
>> (sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed)
>>
>> Fact is that sci-mathematics/sage can't be made work without those deps.
>> Fact is that I want this package and couldn't care less if I have the
>> latest version of these other two packages.
>>
>> If in turn I cared for the other two packages, then I would have to
>> remove sage. It's a choice but nothing else.
>
> it's a crap choice.  users shouldn't have to select from diff sets of packages
> because some are too broken to work properly.  it's a bug and needs to be
> fixed.  and it shouldn't require twisting of arms to make people fix their
> broken packages.

I think you are misrepresenting the choice a bit here. If we aim for
high quality in gentoo-x86 by avoiding deps like this I fear the
choice will not be 'broken foo' or 'working foo' but instead 'broken
foo' or 'no foo' as packages get masked and removed for not keeping up
with the joneses.

Don't get me wrong; I get the impression that there exist vast swaths
of gentoo-x86 that are ...I'll use the term 'poorly maintained' and it
would be good to get some of that stuff out. However I doubt our users
would agree that this is necessarily 'better'.

>
> also, sci-mathematics/sage is a poor example here.  it isn't in the main tree.
> if people want to add poor packages to their overlays, they're free to.
> -mike
>

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Arun Raghavan]

On 2 October 2011 13:50, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 10/02/2011 02:44 AM, Chí-Thanh Christopher Nguyễn wrote:
[...]
>> Bug 361181 is certainly on my TODO list, just not very high up to now.
>> If you think that there is some urgency in getting rid of the package,
>> please do explain so in advance.
>
> The time ran out with opening of http://bugs.gentoo.org/384733 for
> linux-headers reverse deps to be tracked stable.
>
> I've removed qutecom for you again.

Removing the package again seems to just be unnecessary when the
maintainer has stated that he'll fix the problem. Would masking it
till it was fixed not suffice? Seems like a bit unjustified to me
(from information on this thread alone).

Cheers,
-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

On 10/2/11 8:26 PM, Arun Raghavan wrote:
> Removing the package again seems to just be unnecessary when the
> maintainer has stated that he'll fix the problem. Would masking it
> till it was fixed not suffice? Seems like a bit unjustified to me
> (from information on this thread alone).

I find the back-and-forth or the "edit war" most disturbing. Okay, so
the package got removed and re-introduced, and removed and re-introduced...

Please stop canceling each other's actions if possible, just listen and
agree to a solution first. Putting a broken package back into tree is
not solving anything IMO.

Just note I understand possible frustrations if (I haven't verified
things) the removal process was not followed correctly. But whatever the
circumstances, I don't think keeping re-adding the package is the right
solution.

In fact, it seems it would be best to let you guys talk on irc and agree
on some solution.

Finally, forcing downgrades _is_ broken (are you using stable?). If
that's not clear, I'm totally for putting it in the devmanual/quiz or
some other place like that.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Chí-Thanh Christopher Nguyễn]

"Paweł Hajdan, Jr." schrieb:
> I find the back-and-forth or the "edit war" most disturbing. Okay, so
> the package got removed and re-introduced, and removed and re-introduced...

There is no edit war, I restored the package once because I assumed it
was mistakenly removed too early.
When it was removed again then it became clear that it was willful
action and so I refrained from further commits. Also QA told me to not
add it back again.

> In fact, it seems it would be best to let you guys talk on irc and agree
> on some solution.

I wrote to ssuominen on #gentoo-dev IRC, first time on 2011-10-01
11:42:49 UTC after the first removal, last time on 2011-10-02 13:01:41
UTC after second removal.
A discussion between him and other developers ensued, but I never got a
direct reply from him.

His only reaction that was likely directed at me was "grr, who is
chitchan.." at 2011-10-01 18:14:10 UTC, after I restored qutecom.

> Finally, forcing downgrades _is_ broken (are you using stable?). If
> that's not clear, I'm totally for putting it in the devmanual/quiz or
> some other place like that.

I asked for authoritative documentation which forbids downgrades several
times, but got only vague references (and "common sense") as reply.

The arguments I have heard about why downgrading linux-headers is bad is
that it may cause unspecified problems with glibc build (why doesn't
glibc depend on proper linux-headers version then?). And something about
out of tree compiles.

ssuominen himself mentioned
https://bugs.gentoo.org/show_bug.cgi?id=311241#c2 but that talks about
libraries not headers. And a bug comment can hardly be called
authoritative documentation.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Rich Freeman]

2011/10/3 Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org>:
> I asked for authoritative documentation which forbids downgrades several
> times, but got only vague references (and "common sense") as reply.
>

While I'm all for documenting QA policies, ultimately common sense
does need to prevail.  As I've commented before we can't always let a
lack of defined rules keep us from doing the smart thing - or we'll
just turn into a distro ruled by lawyers.  There has to be a balance.

At this point I think this is another tempest in a teapot - the
package shouldn't have been removed yet, and we should try to avoid
removing packages pre-maturely in the future.  That said, having been
removed it doesn't make sense to re-add it until it is fixed, and the
maintainer has agreed to this (grudgingly, and I can understand that).
 As much as it is common sense to not put back a now-broken package,
it also wasn't common sense to pull it out with only two week's notice
in the first place, and as far as I can tell without any effort to
contact the maintainer (not that I'd be aware if an attempt was made).
 It seems likely to me that on a distro the size of Gentoo things like
this can happen without any real malicious intent, and we just need to
learn from our mistakes...

Rich

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

On Sun, 02 Oct 2011 20:48:55 -0700
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:
> Finally, forcing downgrades _is_ broken (are you using stable?). If
> that's not clear, I'm totally for putting it in the devmanual/quiz or
> some other place like that.

We could just ban upper-bounded dependencies that aren't done by slots
inside ebuilds in future EAPIs...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

[Ulrich Mueller]

>>>>> On Mon, 3 Oct 2011, Ciaran McCreesh wrote:

> We could just ban upper-bounded dependencies that aren't done by
> slots inside ebuilds in future EAPIs...

That's probably going to far, as there are valid usage cases.
For example, "|| ( bar <foo-2 )", if your package needs some feature
that was split off from package foo to package bar in version 2.

Ulrich