Re: [gentoo-user] portage alternatives
On 14/03/2015 23:49, Rich Freeman wrote: On Sun, Feb 8, 2015 at 8:32 AM, Alan McKinnon alan.mckin...@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.mckin...@gmail.com
Re: [gentoo-user] portage alternatives
On 15/03/2015 00:34, Rich Freeman wrote: On Sat, Mar 14, 2015 at 6:08 PM, Alan McKinnon alan.mckin...@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.mckin...@gmail.com
Re: [gentoo-user] portage alternatives
On Sat, Mar 14, 2015 at 7:20 PM, Alan McKinnon alan.mckin...@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
On Sat, Mar 14, 2015 at 7:20 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On 15/03/2015 00:34, Rich Freeman wrote: On Sat, Mar 14, 2015 at 6:08 PM, Alan McKinnon alan.mckin...@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...
Re: [gentoo-user] portage alternatives
On Sun, Feb 8, 2015 at 8:32 AM, Alan McKinnon alan.mckin...@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
On Sat, Mar 14, 2015 at 6:08 PM, Alan McKinnon alan.mckin...@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
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
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.mckin...@gmail.com
[gentoo-user] portage alternatives
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
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.vet...@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
