#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:17 spinal84]: > Replying to [comment:14 Bryan Kadzban]: > > > "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. > > If you want to speak grounded about hardness, convenience and complexity you should learn first what is paco, ok? I think you will change your mind about "one person/another person". Just speak about you and it will be truth. But I'm not saying that paco is bad, or good, or whatever. I'm saying that having *any* specific package management scheme in the book instructions is not necessarily a good idea. How well paco works for me (or for you, for that matter) is irrelevant. Let's just say we have ten editors that use five different package management schemes when they build the book -- I don't know if this is true, but it's probably not very far off. If the book contains no package-manager stuff at all, and all ten editors have to do something on top of the instructions to get their package manager setup to work, then the testing that they do is still valid. Their package management scheme will still run the commands in the book, and any bugs in the book should be discoverable. Now if the book adopts one of these schemes, then the two editors that use it will still provide valid testing results. But the other eight won't necessarily, because they will no longer be running what's in the book when they do their builds. Specifically, if the book were to adopt RPM (or whatever: the specific PM doesn't matter), and a future version of rpm introduces a bug, or a future version of some package has a bug when used with rpm, then the editors that don't use RPM will never see that bug. Only the two editors that do use it will ever see it. (Not that there are necessarily two editors that use RPM. But I think my point is clear: it'd be better to have all the editors using the PM in the book, but since I don't think that will happen, it'll be better to make a PM optional.) I do think that Bruce's idea of putting paco at the end of chapter 5 as an optional package, and providing instructions on how to modify the installation commands in chapter 6 to take advantage of it, is a good one. But what I '''don't''' want to do is include the paco commands in chapter 6 itself as "part of the book". As long as users (and editors) can choose something different, and still be using the book, it's fine. > > 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 the book is written mainly for their editors as a "think in itself". I think it's written mostly for linux community. Am I wrong? You're right, but keep reading: I was saying that if the editors don't use what's in the book, then they're not testing the book. :-) > > I don't think that's good for testing; especially not for testing paco-related issues. :-) > > What are you speaking about? If you know any paco-related issues why don't you report em? I don't know of any. That doesn't mean there are none, though, or that including paco will automatically trivially work on everyone's system. (See the above comments on a hypothetical choice of RPM.) If none of the editors use it today, I don't think many of them will want to start, which means they won't be testing the full book contents. Now, there are still users, and there are still bugreports, but it's easier for everyone concerned if the bug never gets into the book in the first place (because the editor making a version change has done a test of the new system, and saw the bug there). > > 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. :-) > > Good point. But maybe first give it a try before making grounded conclusions? Maybe it's not so bad ? :-) If what I'm using works, and provides everything I need it to provide, then why go adopt some different system? :-) > BTW why do you hesitate to point concretely what your favourite package management system is? Partly because its designer has more or less disappeared now (the hint has been adopted, but I'm not sure how that will pan out), but mostly because it's irrelevant. My only point is that it's not paco, and I don't want to go through the work of learning another setup when it won't actually get me anything new that I need. > If you need etherboot then grub is useless for you. If you prefer nano you don't need vim. If you need some kind of editor - use sed, it rocks. Is my idea clear? Sort of. But are you saying that we should introduce a '''new''' required package because certain other packages have alternatives (even ones that work better in certain not-as-common cases)? I don't exactly follow that logic. (Optional would be OK with me, but not required.) Sysvinit is there because we need '''some''' kind of /sbin/init. There are alternatives called out in the book if you want to use something different (or at least there were, although I can't find them anymore; were the references to BSD init and depinit removed?), but you need to do something. We haven't needed a package manager yet, mostly because the prevailing wisdom seems to be that LFS is not a distro. > > ...and besides, vim was in the book when Gerard first wrote it. > > Do you really think it's a good point? What about this: ...and besides, lilo was in the book when Gerard first wrote it. Gerard is not here. And why you think Gerard wouldn't like paco? I have no idea what he would like, as I am not him. I was simply explaining why vim is still present: it was always there, and there hasn't been a real need to remove it. But introducing a new package is rather different than removing one that's already present... (See also the [http://www.linuxfromscratch.org/lfs/view/development/chapter06/pkgmgt.html package management] section in the book. Especially the "Some reasons why no package manager is mentioned in LFS or BLFS include:" part. :-) ) -- Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2111#comment:19> 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
