#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 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?
Look at this scrap from the beginning of the book:
'''
One important reason for LFS's existence is to help people learn how a
Linux system works
'''
I don't see here anything meaning that LFS is only for linux professionals
etc.
> > 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. They are just tools to play with (to get some experience) nothing
more. Oppositely paco is fast, convenient and easy way to manage packages.
Paco is written specially for LFS users. 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" :-) . It's not another RPM, DEB or even tgz. It's the tool to
produce the logs of what is installed in the system with the ability to
process these logs. Paco allows the user to build whatever system he wants
- the user can archive all files in the system using pacoball to make his
own distro, or just leave the logs of installed programs to have the
ability to easily remove/upgrade packages from source code using
instructions from the book.
> > And if someone won't be satisfied with paco (for example some people
making LFS extremely small) they can easy remove paco from the system:
> >
> > {{{
> > # paco -r paco &&
> > rm -fr /var/log/paco
> > }}}
>
> 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? My speech is about someone _doesn't
need_ paco because of the limitations of the system he produced. That's
the only reason I see why someone can desire to remove paco and its logs.
>
> >
> > If someone works on embedded system based on LFS he can use paco to
manage/upgrade system and then remove it when going to production. Even
here paco should be integrated in LFS book.
>
> 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. Most part of LFS is the collection of utilities many of which are
not even essential to the system to be workable but many of them are
introduced just for convenience of the users.
--
Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2111#comment:11>
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
