Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 319923 - net-wireless/hostapd-0.7.2 bump/mask request
Summary: net-wireless/hostapd-0.7.2 bump/mask request
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Bjarke Istrup Pedersen (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-16 07:22 UTC by Peter Volkov (RETIRED)
Modified: 2010-05-17 09:26 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Volkov (RETIRED) gentoo-dev 2010-05-16 07:22:34 UTC
hostapd-0.7.2.tar.gz is out, please bump it in the tree.

Since 0.7.x branch is _developement_ branch are there any reasons to have it in ~arch (and as such being stable branch candidate)? Since upstream still maintains 0.6.x branch and I fail to see why it is not hardmasked. Please, hardmask =net-wireless/hostapd-0.7* as all development versions should be... Thanks.
Comment 1 Thilo Bangert (RETIRED) (RETIRED) gentoo-dev 2010-05-16 08:25:05 UTC
what is breaking, that you want it hardmasked?
Comment 2 Peter Volkov (RETIRED) gentoo-dev 2010-05-16 08:52:31 UTC
As I said - upstream states that this's development version and thus package should be hardmasked until upstream states (or acts, like in mplayer or glibc case) differently. Here as we see upstream clearly separates separates development/stable branches and maintains both, so there is no reason not to hardmask development package.
Comment 3 Peter Volkov (RETIRED) gentoo-dev 2010-05-16 08:59:26 UTC
This masking is documented in our policy and thus should be followed until there are reasons to avoid:

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1

"In another example, if Gimp decides to release an unstable/development series marked as 1.3.0, then these ebuilds should be put in package.mask because the software itself is of development quality and is not recommended by the developers for distribution."
Comment 4 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2010-05-16 09:31:00 UTC
Well, my reason for not hard masking it is, that you need the latest 0.7 version to be able to use the software with >=2.6.33 kernels when using bridges.

Have a look here: http://bugs.gentoo.org/show_bug.cgi?id=298824

Also, there isn't happening any development on 0.6 really (have a look here: http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap-06.git;a=shortlog , only a few commits the last 5 months).

The funny thing is, that the developers of hostapd actually recommends people to try the latest 0.7 version when they hit a bug, so the part you pasted "and is not recommended by the developers for distribution." seems to be mismatching a bit here.

So the right thing to do is to make the ebuild fail if the user is using a 2.6.33 or newer kernel, since 0.6.x isn't compatible with it, and then hardmask 0.7.x ?

Or does upstream recommending people to the 0.7 when they hit a bug count as "until upstream states (or acts, like in mplayer or glibc
case) differently." ?
Comment 5 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2010-05-16 09:59:54 UTC
Anyway, I have hardmasked both hostapd-0.7.* and wpa_supplicant-0.7.* 

Now I'll just sit down and wait for the complaint storm from users how got their wpa_supplicant downgraded by not looking at what "emerge world" would do, and now lost their network access :-D
Comment 6 Peter Volkov (RETIRED) gentoo-dev 2010-05-16 10:33:36 UTC
(In reply to comment #4)

As for upstream's requests to try unstable - that's nothing special here: software does not work for you there is no problem to try unstable but in case problem is fixed there this really simplifies work for upstream. But this is not a reason to use unstable for those who already uses software without any problems.

> don't build on 2.6.33

In such a case I'd better asked upstream explicitly. Such communication is beneficial both for upstream and for us. Upstream will know our needs and in most cases we will get required fixes. Alternatively I don't think it's hard to backport fix, but ... again this is not a reason to force development versions on users until upstream states differently.
Comment 7 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2010-05-16 10:51:37 UTC
(In reply to comment #6)

Regarding several problems, upstream has replied that they will not be backported to 0.6, since there are too much difference between those two.

The way I read that is, that if people want those features in 0.6, they have to do the backport themself, and submit the patches. (Which makes sence, since the time used on the could be used better on improving the 0.7 version)

Anyway, lets see what happens, from what I can read upstream, there shouldn't be too long before a stable version of 0.7 is released.
Until then, people using wpa_supplicant would have to unmask it if they cant connectivity on their machines ;-)
Comment 8 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2010-05-16 18:43:41 UTC
Could you also add (still masked) net-wireless/wpa_supplicant-0.7.2 to the tree?
Comment 9 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2010-05-16 19:11:45 UTC
Sure, but there is already an open bug for that :-)

Regarding the downgrades, my prediction was right - users will lose connectivity :-D
Comment 10 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2010-05-16 19:59:59 UTC
Just re-read the handbook, you forgot an important part:

-------------------------------------------

Moving package versions from ~ARCH to ARCH

When a package version has proved stable for sufficient time and the Gentoo maintainer of the package is confident that the upgrade will not break a regular Gentoo user's machine, then it can be moved from ~ARCH to ARCH. An indication of the package's stability would be no verified or unresolved bug report for a month after the version's introduction.

It is up to the maintainer of the package to deem which versions are stable or if development versions should be in package.mask or left in ~arch.

You must also ensure that all the dependencies of such a package version are also in ARCH. 

-------------------------------------------

The 2nd last paragraph states: "It is up to the maintainer of the package to deem which versions are stable or if development versions should be in package.mask or left in ~arch."

I have removed the masking of those two packages, so they are at ~arch :-)
Comment 11 Thilo Bangert (RETIRED) (RETIRED) gentoo-dev 2010-05-16 20:06:26 UTC
when there is no evidence that the development version breaks, then there
really is no reason to mask it, IMHO.

the development version solves problems for users, while it remains to be seen
that it does introduce (other) problems.

the cited paragraph is generally valid and should be obeyed. however, in this
situation an exemption may be acceptable. different upstreams have different
interpretations on what a development version is and it is the ebuild
maintainers job to make good judgements in this regard. So far the judgement of
this maintainer seems to have served Gentoo and its users right.

Retroactively demanding the package to be hardmasked, while no regressions have
been reported and _thereby_ definitively causing breakage seems backwards from
multiple angles though...

(i wrote this while bjarke wrote the above comment - good move bjarke!)
Comment 12 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2010-05-16 20:16:58 UTC
(In reply to comment #11)

Thanks :-)

Hopefully not too many users got their wireless network broken by this (only heard from one - a fellow developer), so the damage looks minimal :-)
Comment 13 Peter Volkov (RETIRED) gentoo-dev 2010-05-17 09:26:36 UTC
(In reply to comment #10)
> The 2nd last paragraph states: "It is up to the maintainer of the package to
> deem which versions are stable or if development versions should be in
> package.mask or left in ~arch."

This does not interfere with what I said. ~arch is still considered stable candidate.

(In reply to comment #11)
> when there is no evidence that the development version breaks, then there
> really is no reason to mask it, IMHO.

This is where our opinions differ and this is why I filled this bug and bug 319927. Basically my statement is: if there are no good reasons to unmask development package it should be hardmasked. Please, address further comments to bug 319927. I hope I made some clear points there and I would like to improve them if somethings looks bad there.

> the development version solves problems for users, while it remains to be seen
> that it does introduce (other) problems.

Again, what I'm after is that: since this are real problems it's good idea to contact upstream and explain them that until thy release something new, or backport fixes into stable branch they force distributions to use development branches. Sometimes upstream developers do not realize this and communications helps to resolve issue.

> the cited paragraph is generally valid and should be obeyed. however, in this
> situation an exemption may be acceptable. different upstreams have different
> interpretations on what a development version is and it is the ebuild
> maintainers job to make good judgements in this regard. So far the judgement of
> this maintainer seems to have served Gentoo and its users right.

Agreed if judgment is based on good communication with upstream (or lack upstream response or actions...).

> Retroactively demanding the package to be hardmasked, while no regressions
> have been reported and _thereby_ definitively causing breakage seems
> backwards from multiple angles though...

Sure, but again, I disagree with "when there is no evidence that the development version breaks, then there really is no reason to mask it".

BTW, thanks for your comments here. Now I reallize that I was right about different opinions on this matter and I feel that it's good idea to find some general resolution here.