-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hello;
I'm just a gentoo user who has been lurking for a while trying to find
a useful way to help my linux distro. Gentoo was recommended to be as a
good way to get into linux and to rapidly understand the difference
between the way linux works and windows works.
I have to say that for the two years of my university life that i have
used Gentoo for it has taught my a lot.
Now i have never had a problem with portage my self, but since this
thread is in existence there are some definite issues.
Myself as a user would very much have to support Duncan's post below and
as a Computer Science grad would have to say that it makes sense to
clearly define a PMS which should be swappable 1:1 with any other PMS.
To help new users the basic command set should also be the same, tho of
course each PMS can have its own advanced features.
Finally my own personal view of this matter; Gentoo should have and
support its own package manager, it makes sense since one of the key
advantages of Gentoo is to just have to packages you need with just to
support you need i.e. USE flags. Since this is a key goal of the gentoo
project it makes sense to provide a 'default' PM which abides to the
PMS. It also means that there will always be a secure, monitored,
distribution maintained package manager which would guarantee the
distributions basic functionality.
Well there is my 'users' point of view;
As a quick aside, could someone point me in the right direction to help
out with Gentoo, I've got some skills in C and C++ tho my main language
is Java, but I'm a quick learner :P
Duncan wrote:
>
> I keep seeing references to an "official" package manager. Clearly, at
> this point, it's portage, in part because there was no other practical
> reference for deciding whether the ebuild or the handling of it was
> broken. If it worked in portage, therefore, by definition, it was fine.
> (Well, with certain exceptions where portage was held to have bugs, but
> whether it was a bug in portage or not had to be decided before one could
> then rule on whether it was a bug in the tree or not.)
>
> However, now that PMS is finally about to provide what should be a
> definitive description of current generation package behavior, with the
> announced intention to update this with new versions into the future as
> required, the dependence on portage as the reference will soon be going
> away. The announced intention for this, among other things, is to allow
> alternate package managers, such that it can still be clear when it's the
> package broken and when it's the package manager.
>
> So far, so good. However, with such a definitive package behavior
> reference, the question presents itself, with what looks to be several
> possible alternatives waiting, why must Gentoo have an "official" package
> manager at all, and indeed, what purpose, other than name recognition,
> does maintaining such an "official" manager have?
>
> I'd contend that with an appropriate package/tree spec, as soon as we
> have multiple package managers meeting that spec, then we /don't/ /need/
> an "official" package manager. Perhaps one /recommended/ by default in
> the documentation, sure. Perhaps one that ships on the official Gentoo
> LiveCD installers, sure. However, all this arguing over "official"
> package manager is worthless, IMO. Let the alternatives each stand on
> their own merits, just as we do with all sorts of other choices,
> optionally with one recommended for newbies who don't have any reason of
> their own to prefer one over another and likely with one used to build
> official media, but without any of them recognized as the /official/
> package manager, because there's simply no continuing need for such a
> thing, once the extents and limits of acceptable package behavior at a
> particular API level has been appropriately speced out.
>
> If this approach were taken, it wouldn't have to affect releng much at
> all, certainly short term, since they could continue using portage, which
> is assumed to continue to be one of the recognized and accepted
> alternatives. Longer term, it would only as they found reason to switch
> to other alternatives, and if they didn't find such reason, well... It
> would affect bugs very little as well, since there are already bugs where
> it ends up being a package manager regression, only now, such regressions
> would be measured against the package spec, rather than against past
> behavior of any particular package manager (except as necessarily encoded
> in that spec, for the first version, anyway), and there'd now be a
> definitive way to say for sure whether it was the package manager or the
> package.
>
> Documentation, there'd necessarily be some adjustment. However, the
> documentary focus could remain on the "recommended" package manager,
> referring to the individual manager's documentation if they'd made a
> choice other than the "recommended" choice. Certainly, it would behoove
> the maintainers of alternative package managers to create compatible
> documentation if they wished to go very mainstream, but nothing would
> force the docs project into massive changes except as such docs were
> ready and then only in cooperation with the arch teams and releng re the
> recommendations in the handbook.
>
> What about infra? What about Mike's worry of securing Gentoo access to
> at least one of its package managers? How about this? Maybe it has
> holes in it, but it should provide at least a minimum security level, and
> combined with an "open" package manager spec encouraging multiple
> alternative implementations, I think it's likely to be found workable in
> practice. Require for any "approved" package manager, not that the
> working repository /has/ to reside on Gentoo infrastructure, but that a
> repository mirror, routinely updated every 24 hours at minimum, be
> maintained on Gentoo infra. For approval, this must be a /complete/
> mirror. However, if appropriate and necessary, it may be restricted
> access. (Hash out the requirement further as necessary, but the idea
> being that if access is restricted, the council and probably at least one
> member of Gentoo security must have access.) For approval, the license
> would be required to be be acceptably open to allow a fork if necessary,
> and presumably at least one Gentoo developer on the package manager
> development team wouldbe required as well, with two or more encouraged to
> prevent issues due to retirements or the like. (If the number of
> approved package managers should ever exceed three, access and Gentoo dev
> requirements may be relaxed as found appropriate.)
>
> In summary, there would be no "official" Gentoo package manager as such,
> but ideally, several "approved" managers, plus perhaps some in the
> community not officially approved. Recommendations would however be
> allowed, with docs presumably favoring the recommended option, and releng
> free to use what they felt best in cooperation with the various teams
> they work with. PM/pkg bug responsibility would be according to the
> official package spec. Package managers wouldn't be required to be
> developed on Gentoo infrastructure, but for official approval, if the
> repository were not on Gentoo infra, a repository mirror on Gentoo infra
> would be required. If the package manager were independently developed,
> appropriate licensing and the presence of a Gentoo developer on the
> package manager development team, thus ensuring continued continuity for
> Gentoo should the independent project dry up and blow away or the like,
> would be necessary for approval. Approval requirements may be relaxed to
> some degree if the number of approved alternatives is found to be enough
> to eliminate danger of shortage.
>
> I'm sure there are holes in the above, there always are in first drafts.
> However, I just don't see it necessary to squabble over the status of
> "official" package manager after introduction of a suitable package spec,
> because I see no reason for there to /be/ such an "official" package
> manager, but rather a group of "officially approved" managers, given that
> options exist, with approval contingent on reasonable implementation of
> the package spec among other things, of course.
>
- --
.Adam Pickett
[EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGD5VyApBPo0RrzjERAnELAKDKbrGdH5UcmXvq6hsYEsfpdylWnwCgzH7K
9StBe0V9EhxmH84D0snX8f0=
=CmP1
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
