[gentoo-user] portage alternatives

[gentoo-user] portage alternatives

[Michael Vetter]

Hello list,

just for fun I am reading about alternatives to portage. So far the most
interesting I found are: paludis and pkgsrc.

paludis mostly because it seems to come from some gentoo-like enviroment
and pkgsrc because of the nice thought to have the same pkg files for
multiple OSes.

Is anybody of you using one of them and can tell me about pros and cons?

regards

-- 
Michael

Re: [gentoo-user] portage alternatives

[Bob Wya]

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

Michael,

I tried out paludis a few months ago. I do find Portage can be a bit slow.
So I thought great - a "C++ version of Portage"!

However cave does do much stricter checking and has much more verbose
output than emerge (way too much - like eix I guess). I really gave it my
best shot to migrate over fully - but had to bale after a couple of weeks
of trying to get one clean upgrade cycle. Speed wise - cave was slower than
emerge (with no backtracking). So regular day-to-day installs would be
quite slow (with the package tree being churned over multiple times).

I'm sure I'll give it another go at some point... Maybe I was simply using
it wrong... But boy it felt like it was for geeks who think "Portage is way
too easy - give me something much harder"!!

Robert



On 2 February 2015 at 10:26, Michael Vetter <michael.vetter@uni-konstanz.de>
wrote:

> Hello list,
>
> just for fun I am reading about alternatives to portage. So far the most
> interesting I found are: paludis and pkgsrc.
>
> paludis mostly because it seems to come from some gentoo-like enviroment
> and pkgsrc because of the nice thought to have the same pkg files for
> multiple OSes.
>
> Is anybody of you using one of them and can tell me about pros and cons?
>
> regards
>
> --
> Michael
>
>


-- 

All the best,
Robert

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

Re: [gentoo-user] portage alternatives

[Thomas Mueller]

> from Michael Vetter:

> just for fun I am reading about alternatives to portage. So far the most
> interesting I found are: paludis and pkgsrc.

> paludis mostly because it seems to come from some gentoo-like enviroment
> and pkgsrc because of the nice thought to have the same pkg files for
> multiple OSes.

> Is anybody of you using one of them and can tell me about pros and cons?

I've read a bit about paludis, the package manager in Exherbo, forked from Gentoo, but haven't got to try it yet.

I am familiar with pkgsrc, use only in NetBSD where it is native.

For FreeBSD, I use the FreeBSD ports, notice that pkgsrc seems to have nothing to compare to portmaster and portupgrade.

In pkgsrc, you can update all packages with pkg_rolling-replace, but not so easy to update just one package/port and its dependencies.

pkgsrc seems directed at BSD, where there is a distinction between packages and base system.

In Linux, I get the impression that everything is a package, including what would be part of a BSD base system and not well-covered in pkgsrc.

I've fallen behind on following this list, too many emails elsewhere, which is why I'm late in responding here.

Tom

Re: [gentoo-user] portage alternatives

[Alan McKinnon]

On 08/02/2015 11:54, Thomas Mueller wrote:
>> from Michael Vetter:
> 
>> just for fun I am reading about alternatives to portage. So far the most
>> interesting I found are: paludis and pkgsrc.
> 
>> paludis mostly because it seems to come from some gentoo-like enviroment
>> and pkgsrc because of the nice thought to have the same pkg files for
>> multiple OSes.
> 
>> Is anybody of you using one of them and can tell me about pros and cons?
> 
> I've read a bit about paludis, the package manager in Exherbo, forked from Gentoo, but haven't got to try it yet.
> 
> I am familiar with pkgsrc, use only in NetBSD where it is native.
> 
> For FreeBSD, I use the FreeBSD ports, notice that pkgsrc seems to have nothing to compare to portmaster and portupgrade.
> 
> In pkgsrc, you can update all packages with pkg_rolling-replace, but not so easy to update just one package/port and its dependencies.
> 
> pkgsrc seems directed at BSD, where there is a distinction between packages and base system.
> 
> In Linux, I get the impression that everything is a package, including what would be part of a BSD base system and not well-covered in pkgsrc.

Correct. With most Linux package managers, everything is a package and
everything has strict dependencies. You install the bits you want and
the PM installs the bits it needs.

Gentoo is one of the very few PMs that even has a concept of @system at all





-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] portage alternatives

[Rich Freeman]

On Sun, Feb 8, 2015 at 8:32 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> Correct. With most Linux package managers, everything is a package and
> everything has strict dependencies. You install the bits you want and
> the PM installs the bits it needs.
>
> Gentoo is one of the very few PMs that even has a concept of @system at all
>

To be honest, I think this is one of its larger deficiencies, and it
causes many problems.

IMHO, the only reason we have @system is that devs create dependencies
entirely by hand and most don't want to actually document what they
are.  Of course, the need to build packages give Gentoo packages a
large number of build-time dependencies, but any distro that allows
packages to be built from source has to deal with this as well.

Sure, to bootstrap anything you need to start out with something, but
that doesn't mean that you can't still track what the actual
dependency relationships are, and in any case our system set is larger
than the set of packages necessary to bootstrap the rest of the
distro.  Of course, it is hard to say exactly what is and isn't
necessary for bootstrapping since we don't capture our dependencies.

-- 
Rich

Re: [gentoo-user] portage alternatives

[Alan McKinnon]

On 14/03/2015 23:49, Rich Freeman wrote:
> On Sun, Feb 8, 2015 at 8:32 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> Correct. With most Linux package managers, everything is a package and
>> everything has strict dependencies. You install the bits you want and
>> the PM installs the bits it needs.
>>
>> Gentoo is one of the very few PMs that even has a concept of @system at all
>>
> 
> To be honest, I think this is one of its larger deficiencies, and it
> causes many problems.
> 
> IMHO, the only reason we have @system is that devs create dependencies
> entirely by hand and most don't want to actually document what they
> are.  Of course, the need to build packages give Gentoo packages a
> large number of build-time dependencies, but any distro that allows
> packages to be built from source has to deal with this as well.
> 
> Sure, to bootstrap anything you need to start out with something, but
> that doesn't mean that you can't still track what the actual
> dependency relationships are, and in any case our system set is larger
> than the set of packages necessary to bootstrap the rest of the
> distro.  Of course, it is hard to say exactly what is and isn't
> necessary for bootstrapping since we don't capture our dependencies.


That's all very true, witness the frequent bikeshedding in -dev about
what should and shouldn't be in @system. It looks like a simple problem
- you need a toolchain plus all supporting packages plus the minimum
needed to bootstrap userland.

But let's consider this: what level of chaos would arise if @system were
dropped? Surely the problem of tracking all deps would get so out of
hand so quickly, that @system or something equivalent would immediately
be reinstated?



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] portage alternatives

[Rich Freeman]

On Sat, Mar 14, 2015 at 6:08 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> But let's consider this: what level of chaos would arise if @system were
> dropped? Surely the problem of tracking all deps would get so out of
> hand so quickly, that @system or something equivalent would immediately
> be reinstated?
>

I don't think so.  Why don't other distros have this problem with
their source packages?  They actually have more packages to deal with
since they don't have use flags and often split what is one Gentoo
package into many packages.

You can still have virtuals when it makes sense to have them.
Automation might be an option in some cases as well.  If a package
uses gcc and python, there is no reason that this couldn't be two
virtuals in addition to whatever specific libraries it requires.  You
could also have virtuals for posix and such.

We would also separate virtuals intended for user convenience (give me
a useful system, maybe including screen and ssh and such) from
virtuals intended for dependencies (you don't need screen and ssh to
build everything on the system).  There is no reason that the default
install has to start with only the core dependencies, or with an empty
world set.


-- 
Rich

Re: [gentoo-user] portage alternatives

[Alan McKinnon]

On 15/03/2015 00:34, Rich Freeman wrote:
> On Sat, Mar 14, 2015 at 6:08 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>
>> But let's consider this: what level of chaos would arise if @system were
>> dropped? Surely the problem of tracking all deps would get so out of
>> hand so quickly, that @system or something equivalent would immediately
>> be reinstated?
>>
> 
> I don't think so.  Why don't other distros have this problem with
> their source packages?  They actually have more packages to deal with
> since they don't have use flags and often split what is one Gentoo
> package into many packages.

Other distros DO have the same problem, just framed differently.

On Debian you need build-essential whether the source package declares
it or not. Now what is build-essential, if not @system cloaked
differently? Yes, @system has much more stuff in it and even some cruft,
but both things fulfil the same function.

In my experience the general approach from a binary distro is to tell
you to install build-essential or equivalent if you want to compile
stuff. If you forget, there's Google to remind you


> You can still have virtuals when it makes sense to have them.
> Automation might be an option in some cases as well.  If a package
> uses gcc and python, there is no reason that this couldn't be two
> virtuals in addition to whatever specific libraries it requires.  You
> could also have virtuals for posix and such.
> 
> We would also separate virtuals intended for user convenience (give me
> a useful system, maybe including screen and ssh and such) from
> virtuals intended for dependencies (you don't need screen and ssh to
> build everything on the system).  There is no reason that the default
> install has to start with only the core dependencies, or with an empty
> world set.

I don't follow. How do virtuals connect with @system?
Are you suggesting separating @system out into several more narrowly
defined virtuals?

I'm undecided on the wisdom of that approach. My own preference would be
to replace @system with several regular sets


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] portage alternatives

[Rich Freeman]

On Sat, Mar 14, 2015 at 7:20 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> I don't follow. How do virtuals connect with @system?
> Are you suggesting separating @system out into several more narrowly
> defined virtuals?

Essentially.

>
> I'm undecided on the wisdom of that approach. My own preference would be
> to replace @system with several regular sets

I don't believe you can use sets as a package dependency.  You also
lose the ability to do versioning/etc if appropriate.

-- 
Rich

Re: [gentoo-user] portage alternatives

[Tom H]

On Sat, Mar 14, 2015 at 7:20 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 15/03/2015 00:34, Rich Freeman wrote:
>> On Sat, Mar 14, 2015 at 6:08 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>>
>>> But let's consider this: what level of chaos would arise if @system were
>>> dropped? Surely the problem of tracking all deps would get so out of
>>> hand so quickly, that @system or something equivalent would immediately
>>> be reinstated?
>>
>> I don't think so. Why don't other distros have this problem with
>> their source packages? They actually have more packages to deal with
>> since they don't have use flags and often split what is one Gentoo
>> package into many packages.
>
> Other distros DO have the same problem, just framed differently.
>
> On Debian you need build-essential whether the source package declares
> it or not. Now what is build-essential, if not @system cloaked
> differently? Yes, @system has much more stuff in it and even some cruft,
> but both things fulfil the same function.
>
> In my experience the general approach from a binary distro is to tell
> you to install build-essential or equivalent if you want to compile
> stuff. If you forget, there's Google to remind you

In Debian there's the concept of "Required" packages (that are
required for the system to run) and "Important" packages (that are
available on any Unix system). They're on every Debian system. Those
of them that are marked "Essential" cannot be ninstalled.

"build-essential" is a metapackage that, mostly, pulls in gcc, make,
patch, and linux and libc headers (and other packages tagged as
"Build-Essential" in their control files) so you could say that
"Required"+"Important"+"Build-Essential" add up to "@system", although
from a binary distro's perspective it'd be more accurate to say that
"Required"+"Important" add up to "@system".

There was an email earlier in this thread about bikeshedding about
what should or shouldn't be in "@system". There's the same
bikeshedding about "Required"/"Important"/"Essential" in Debian (and
"@standard" in Fedora; previously "@core"+"@base"). It's part of the
process of maintaining a distro...