public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Chí-Thanh Christopher Nguyễn" <chithanh@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012
Date: Tue, 30 Oct 2012 23:06:30 +0100	[thread overview]
Message-ID: <50904F66.8070808@gentoo.org> (raw)
In-Reply-To: <20121030150024.GU85698@gentoo.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear all,

I wish to ask that the council makes a statement regarding the policy
on "<" versioned dependencies.

Some time ago one of the ebuilds that I maintain was removed twice
without my consent, the reason given that it violates an alleged
policy which forbids <sys-kernel/linux-headers-2.6.38 dependency[1].
After some discussion, the issue was resolved by fixing the build with
newer linux-headers. About the policy itself, no consensus was reached.

The issue came up again later[2] and also recently with some x11
maintained packages[3]. Today in the boost discussion thread on -dev
it was brought up too.

If I understand correctly, the proponents of this policy call for some
kind of reverse visibility requirements, where stabilizing or
unmasking a package requires all reverse dependencies on that slot to
work with the newly stabilized/unmasked version.

I dispute that such a policy exists, and am not aware of any
authoritative document that says so. When asking for documents that
describe this policy, I was only pointed to common sense.

The reason why I think that < dependencies are not bad is that
existing users of such packages will typically simply miss out on
upgrades. Worst case is that trying to newly install a package can
lead to downgrades or slot conflicts. But the user can see this before
the build starts, and still decide to abort or uninstall one of the
problem packages.

The reason why I think that forbidding < dependencies is bad is that
in the case of x11 maintained packages, their development speed is
non-uniform. Especially new xorg-server releases can have certain
x11-drivers packages depend on old versions for weeks or even months.
Masking xorg-server will hinder X.org progress for everyone else, and
removing the drivers that continue to work fine with old xorg-server
would be a disservice to users.

I therefore ask the council to:
1. State whether such a policy exists
2. If it exists, repeal this policy
3. If the policy exists and is not repealed, state what is done with
packages in violation of that policy (e.g. must they be treecleaned,
or is it sufficient to p.mask them or drop to ~arch?)


Best regards,
Chí-Thanh Christopher Nguyễn


[1] https://bugs.gentoo.org/show_bug.cgi?id=361181
[2] https://bugs.gentoo.org/show_bug.cgi?id=414997
[3] https://bugs.gentoo.org/show_bug.cgi?id=439714
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCQT2YACgkQ+gvH2voEPRB7OACePIMpS1g/G3vQ/yUp2/ngSMVB
1W0AnRANyPZoANZ8mW4ErjcrwS/+wSuH
=mzoU
-----END PGP SIGNATURE-----


  parent reply	other threads:[~2012-10-31  0:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-30 15:00 [gentoo-project] Call for agenda items -- Council meeting 13-11-2012 Fabian Groffen
2012-10-30 15:36 ` William Hubbs
2012-10-30 16:21   ` Ian Stakenvicius
2012-10-30 16:38     ` William Hubbs
2012-11-02 17:22       ` William Hubbs
2012-11-08 17:07       ` Alexis Ballier
2012-11-08 17:38         ` William Hubbs
2012-10-30 22:06 ` Chí-Thanh Christopher Nguyễn [this message]
2012-10-30 22:09   ` Ciaran McCreesh
2012-10-30 22:11     ` Chí-Thanh Christopher Nguyễn
2012-10-30 22:34       ` Zac Medico
2012-10-31  6:41   ` Pacho Ramos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50904F66.8070808@gentoo.org \
    --to=chithanh@gentoo.org \
    --cc=gentoo-project@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox