Re: [gentoo-dev] Re: [soc] Python bindings for Paludis

[Mike Auty]

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

Duncan wrote:
> The point being, however, that all this quarreling about "official"
> package managers doesn't /really/ have to happen. [...]
>  I just don't see why so many are spending
> so much time arguing over it, when regardless, people are going to make
> their choices, and "official" status won't matter so much when people do
> so, because the package spec and what works is going to be the defining
> factor, not some "official" blessing, except indirectly as that affects
> further package spec updates.

	I agree that the title "official" is nothing more than a title or label
and will most likely be applied to the most common/popular manager.  I
think the reason for the discussion is that arguably Gentoo has been
goal-less or at the very least major-project-less, and developers with
vision are nervously looking for the direction to push the project.
Personally, I'm very happy with Gentoo as is, it's flexible, I can add
the packages I might find when browsing the web and it does everything I
need.  I don't need a major direction, or a big change, or an upheaval,
or pretty much anything else, and I believe many of the less vocal
developers feel similarly.
	However, for those that are looking for a change (and sunrise and seeds
both seem recent evidence that a body of developers are looking for a
change), then I think the alternative package manager is a nice big area
with big uncertainty, given that it's well developed source-based
package management is arguably the unique selling point of Gentoo.  I
think if someone were writing a "new" portage that simply took over from
the old one one day, there would be nowhere near as much discussion.
Therefore, the issue at the heart of these threads is the possibility of
splintering of the project.
	There are quite clearly two sides.  Those that would like to see
multiple package managers: their reasoning is that they'd like to offer
an alternative, with features and designs that would be difficult to
integrate into the existing code, and some decisions that would break
with the current design (albeit slightly).  The other side doesn't
necessarily fear another, better package manager, but fears that
allowing multiple package managers will start to cause incompatibilities
and will divide both the user group and the developer group.  Overlays
are a feature capable of this division, and already it's given rise to
the "seeds" idea, which again met with the same dissent: that of divided
time and resources spent on a number of smaller Gentoos, each with less
popularity, less time devoted to each, and the difficulty of
re-integration with the main branch.
	Nobody actively wants to break the main tree, but no one has yet
figured out a way of ensuring that users do not encounter disruption if
they decide to use a different package manager.  The PMS is a step to
overcome this by defining a standard, or interface, to ensure compatibility.
	So how can we smooth the way between the two sides?  The best I can
come up with is a more complete specification.  One that includes both
the package format, and the local state required to store data.  The
Pros for this, are that package managers could become interchangeable,
to the point that it would never matter which package manager were in
use at the time.  The cons for this idea, are that it would slow down
the development, changes and feature additions to the various managers,
as the changes must first pass through the specification and then
finally be implemented.
	We've already seen (with the introduction of Manifest2) that changes to
the tree and distribution mechanism are slow at best (I believe manifest
signing is over two years old and still not in place for every
package?).  Requiring adherence to a specification, and maintaining that
specification will be even more difficult and slow, but it would allow
both sides to move on, and work together towards the new direction.
	So now the question is, are we willing to accept the cons for the pros,
or do we need to find a different solution.  If not, then other package
managers should invest their time in ratifying a specification quickly,
so that they can get down to coding to the specification.  Also, those
against a new manager, should get down to agreeing the specification so
that managers with the possibility of fracturing are bound within a
framework of acceptability.  As I see it, that leaves both sides working
towards the same direction, and should give impetus to both groups to
come to a common point as fast as possible.
	If not, then probably we should return to the drawing board, but I
concur that bickering and worrying about the future without pinpointing
the problem and trying to tackle it, is far more futile than working
towards a viable solution...
	Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)

iD8DBQFGEDWOu7rWomwgFXoRAl4bAJ9PHn6kzSB3ChzXer9+3dxm6nSj/gCfTAJ1
moZTFrQjlMqyUF2v54sz88E=
=A8vf
-----END PGP SIGNATURE-----
-- 
gentoo-dev@g.o mailing list