#2111: Adding PACO to LFS -------------------------+-------------------------------------------------- Reporter: spinal84 | Owner: [email protected] Type: enhancement | Status: new Priority: low | Milestone: 7.0 Component: Book | Version: 7.0 Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by Bryan Kadzban):
Replying to [comment:11 spinal84]: > Replying to [comment:8 [EMAIL PROTECTED]: > > Replying to [comment:6 spinal84]: > > > > > > Almost everybody using LFS needs good package management tool. All these techniques from the book are very hard to understand to newbies in linux and LFS. > > > > Newbies to linux aren't supposed to be building LFS in the first place. > > > > I built my first LFS system being newbie. Why not? Because complete Linux newbies are not the book's target audience. (That's the same reason that we added the prerequisites page: [http://www.linuxfromscratch.org/lfs/view/development/prologue/prerequisites.html]) > I don't see here anything meaning that LFS is only for linux professionals etc. Not professionals (only), no. But it's not intended for complete newbies either (by that I mean people who have never used any version of Linux before). > > > I think everybody like orderliness in their linux systems. I read about other package management systems in LFS. They all are hard, complicated and/or inconvenient not only for newbies but experienced users too. Just want to comment on that: I don't think it's right. The "package manager" scheme that I use personally is quite easy for me (mostly because I'm used to it) -- "hard", "complicated", and "inconvenient" are all dependent on who's making the decision. What's inconvenient for one person isn't necessarily inconvenient for everyone. Plus, adding paco to the official LFS book as a '''requirement''' would mean that at least one editor (me), and probably a fair number of others, would no longer actually run the real LFS system, because they'd want to use whatever package management scheme (if any!) that they use today. I don't think that's good for testing; especially not for testing paco- related issues. :-) > > > Why not include it as native package management tool? > > > > Because adding a native packagement to LFS would just turn LFS into another distro, and partially eliminate the point of LFS - to build whatever system you want. > > How will it eliminate that point? If you don't like phrase "package management", call PACO "file management tool with the ability to manage packages" :-) But why force everyone to use it, instead of whatever they already have? (Or isn't that what you're proposing?) It will eliminate the ability to build "whatever system you want" because if you integrate the paco stuff into the build instructions in chapter 6, then people that don't use paco won't be building the "real" LFS book anymore. > > I'm of the opinion that it's always easier to add something like paco (or any other package management scheme, or even any package in general) to generic (non-package-management-specific) instructions, than to have the book assume package management and expect users to *remove* that if they don't want it. > > Why someone will not want to use paco? I'm not sure about anyone else, but I don't want to use it because I already have a package management system (that '''isn't''' paco) that I want to keep using. I don't think I'd ever heard of paco before this ticket was created, actually. :-) > > LFS should not use any package management scheme. It's not that difficult to simply take whatever package management techique you want and integrate it into your own LFS system. > > Continuing your idea: LFS doesn't need grub, sysvinit, vim and many other packages as it's not that difficult to simply take whatever boot loader, initializing system or editor you want and integrate it into your own LFS system. That is true, sort of. You need '''some''' bootloader and '''some''' initialization system, though (otherwise your system won't boot), and grub/sysvinit are as good as any other. If a package manager was required to get Linux to boot, then we'd have one system or another in the book already. Now, vim doesn't fall into that category, because you don't really need an editor to get the system up and running. But you do need an editor more often than you need a package manager, IMHO (you need an editor of some sort whenever you change a file; you only really '''need''' a package manager when you need to remove something or figure out where a file came from) -- and besides, vim was in the book when Gerard first wrote it. Sysvinit falls into that category as well (I think): it's been in the book from the first version. Grub doesn't, but we switched from lilo for one reason or other (can't exactly remember why anymore). None of these packages have been removed -- although alternatives are usually mentioned in the appropriate package page(s) in chapter 6 -- because there's a requirement for most of them for the system to boot. However, package management wasn't added because there is no similar requirement for it when you boot. (The other stuff mostly got grandfathered in because it was there when the book was first written.) To be clear: I'd have no problem with another project or sub-project showing how to do package management (as Ag has said), although we do currently have a few different hints on the subject. (Including one on [http://www.linuxfromscratch.org/hints/downloads/files/paco.txt Paco itself].) But I'd really rather not add a specific package manager to the book, except (perhaps) as an option at the end of chapter 5. Even then, though, that package manager would have to be something that at least gets some testing from the editors; maybe paco does? I'm not sure. -- Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2111#comment:14> LFS Trac <http://wiki.linuxfromscratch.org/lfs/> Linux From Scratch: Your Distro, Your Rules. -- http://linuxfromscratch.org/mailman/listinfo/lfs-book FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
