Adding PACO to LFS

[Arthur Demchenkov]

There's package management tool written specially for LFS. It's very convenient and easy to use comparing to other package management techniques from the book. I think it's now stable enough to be included in LFS book.

Homepage: ​http://paco.sourceforge.net

[alexander@…]

-1. DESTDIR-style is the mainstream approach today. OTOH, if PACO gets an option to use DESTDIR instead of (or together with) LD_PRELOAD, I will reconsider.

[dnicholson@…]

How would paco prevent you from using a DESTDIR?

[Matthew Burgess]

I'm really not sure that LFS needs to do anything more regarding package management. We already point out various alternative package management schemes. With the work that's going on in jhalfs regarding getting 'hooks' in place, I'd imagine hooking up a package manager such as paco to jhalfs will be possible.

I still see LFS as the base of these other requirements. We provide the instructions required to build a (hopefully) robust yet small Linux system. Other projects, such as blfs, jhalfs, etc. provide additional features on top of that. While LFS does adapt to allow easier integration of these other projects, I don't know of anything else that LFS needs to do in order to accomodate package managers.

Matt.

[alexander@…]

Replying to dnicholson@linuxfromscratch.org:

How would paco prevent you from using a DESTDIR?

I want packages (or, more precisely, their file list) that one has packaged through DESTDIR (as opposed to LD_PRELOAD) to show up in the paco database correctly.

[alexander@…]

Replying to matthew@linuxfromscratch.org:

I don't know of anything else that LFS needs to do in order to accomodate package managers.

Optional DESTDIR support like that provided by DIY-Linux (so that it becomes a no-op if a package manager is not used).

[Arthur Demchenkov]

Replying to matthew@linuxfromscratch.org:

I'm really not sure that LFS needs to do anything more regarding package management. We already point out various alternative package management schemes.

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. Taking in account my experience in LFS the first time I installed all LFS packages using instructions from the book. Then I installed some packages from BLFS. Then I found the tool called PACO, I installed it and saw it's good and what I needed for long time ago. Of course in some time I had to reinstall all my LFS+BLFS system just to use paco because my upgrades scattered the system.
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?

I still see LFS as the base of these other requirements. We provide the instructions required to build a (hopefully) robust yet small Linux system.

$ paco -s paco
318k  paco-2.0.3

Paco size in my system is only 318kb (without stripping). I hope it's no too big for LFS? ;-)

Other projects, such as blfs, jhalfs, etc. provide additional features on top of that.

I'm not speaking about including paco as addition feature. I'm speaking about making paco the one of the heart tools for LFS system just like linux kernel. It should be native package management tool for LFS. Just like grub is made native boot loader in opposition to lilo and others.

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

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.

[Arthur Demchenkov]

Replying to alexander@linuxfromscratch.org:

Replying to dnicholson@linuxfromscratch.org:

How would paco prevent you from using a DESTDIR?

I want packages (or, more precisely, their file list) that one has packaged through DESTDIR (as opposed to LD_PRELOAD) to show up in the paco database correctly.

Just to make it clear. Do you want paco to log the packages without installing? Or you just want this:

make DESTDIR=$MYDESTDIR install
paco -lp $PACKAGENAME "cp -vpR $MYDESTDIR/* /"

[Chris Staub]

Replying to 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 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.

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.

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.

[bdubbs@…]

I took a look at paco and it seems to be well done.

This discussion seems to indicate that there is a demand for this type of thing.

I have no objections to adding the command line only version of paco as the last package in Chapter 5 and declaring it optional. The page could also provide limited instructions about how to use it in an LFS command line environment, including the chroot environment.

Changing the install instructions in the packages of Chapter 6 to use DESTDIR seems like a reasonable thing to do to provide flexibility, but putting the actual command to use paco in every package would seem like a task that should be left to the user.

[Ag. Hatzimanikas]

I believe that the DESTDIR approach is the right answer to package management issue, once for all.

I am against to add a specific package manager to the Book, unless that specific tool is actively maintained from our organization.

Another thing that we often underestimate or we don't give enough emphasis is that, if you work with XML sources (both for Lfs and Blfs), there are targets in the Makefile to generate scripts (make dump-commands) and download scripts (make wget-list). Accommodated with the DESTDIR method, these are more than enough for everyone with a little effort to create personal scripts for any kind of automation and to keep logs of the installed files.

[Arthur Demchenkov]

Replying to chris@linuxfromscratch.org:

Replying to 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.

[Arthur Demchenkov]

I believe that the DESTDIR approach is the right answer to package management issue, once for all.

Some packages doesn't use DESTDIR approach. That's not a panacea.

I am against to add a specific package manager to the Book, unless that specific tool is actively maintained from our organization.

Does someone interrupt you from maintaining of PACO? The main developer is friendly enought and responsive man.

Another thing that we often underestimate or we don't give enough emphasis is that, if you work with XML sources (both for Lfs and Blfs), there are targets in the Makefile to generate scripts (make dump-commands) and download scripts (make wget-list). Accommodated with the DESTDIR method, these are more than enough for everyone with a little effort to create personal scripts for any kind of automation and to keep logs of the installed files.

Just belive me scripting with paco is very easy. And it works where DESTDIR approach is absend. Another think that you underestimate is that paco is useable in packages that are not covered in any of (B,H,C)LFS books.

[Ag. Hatzimanikas]

Replying to spinal84:

I am against to add a specific package manager to the Book, unless that specific tool is actively maintained from our organization.

Does someone interrupt you from maintaining of PACO? The main developer is friendly enought and responsive man.

The problem is not if he is friendly or not. What you ask with your ticket (or what I think you ask) is to integrate paco commands into the book. So we will base our method (and our commands) in a tool which is developed outside of our organization. That means we will not have total control over it. That is unacceptable.

Another thing to consider is that, and since our provided books gives to the reader the know how to create a *custom* distribution for any use and purpose; by using a specific tool, it takes away that freedom of choice. What is the most interesting part of our books, and it will have to stay like this in the foreseeable future, are the plain commands.

If there is enough interest to use Paco or any other tool for that matter, this is a job that should be done outside of the book, that means a different book and a different subproject. For the latter we already have Alfs and Jhalfs. And I remember that there was a jhalfs patch about paco, I don't know if it is still under maintaince, I think is not, but I am sure it won't be too difficult to re-add it as a complementary component.

As for the former, yes, I always believed that there had to be a book dedicated for package management, explaining in depth various techniques and quite probably using a dedicated tool. That is a discussion though that needs a new ticket and most importantly a couple of passionated guys to create that book who will mix the power of XML and the automation modern techniques with the proper tools. A book which has to be built on top of Jhalfs or a new generation tool. I thought I noticed a discussion started by Jeremy but it was during my long absense so I am not sure if there is an effort or not.

But I agree in principle that the package managment issue has to be resolved with one way or another. Even if it is as an educational project. "How to manage a distribution." I think it will be interesting.

[bryan@linuxfromscratch.org]

Replying to spinal84:

Replying to chris@linuxfromscratch.org:

Replying to 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 ​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.

[alexander@…]

Replying to spinal84:

Just to make it clear. Do you want paco to log the packages without installing? Or you just want this:

make DESTDIR=$MYDESTDIR install
paco -lp $PACKAGENAME "cp -vpR $MYDESTDIR/* /"

I want something like the code above (because it tracks actions of setuid programs correctly), but also I want to register info pages and gconf keys correctly (that's why "cp -R" doesn't work). Also, I want creation of binary packages that can be installed to the other machine (but this is a feature request that doesn't block this bug).

[alexander@…]

Replying to spinal84:

I believe that the DESTDIR approach is the right answer to package management issue, once for all.

Some packages doesn't use DESTDIR approach. That's not a panacea.

I disagree. Even if a package doesn't allow installation to a non-root directory with DESTDIR (for preview or for packaging), it must be patched to do so or its installation instructions modified accordingly. It is done in DIY-Linux, because it is unavoidable for building binary packages, especially as non-root. That's how all distro packages are created, i.e. instructions already exist for all software in the worls. Why should LFS ignore this or be different?

[Arthur Demchenkov]

Replying to Bryan Kadzban:

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.

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.

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?

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?

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. :-)

Good point. But maybe first give it a try before making grounded conclusions? Maybe it's not so bad ? :-)

BTW why do you hesitate to point concretely what your favourite package management system is?

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.

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?

...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?

Sysvinit falls into that category as well (I think): it's been in the book from the first version.

Again. Do you really think it's a good point?

[Arthur Demchenkov]

Replying to bdubbs@linuxfromscratch.org:

I took a look at paco and it seems to be well done.

This discussion seems to indicate that there is a demand for this type of thing.

I have no objections to adding the command line only version of paco as the last package in Chapter 5 and declaring it optional. The page could also provide limited instructions about how to use it in an LFS command line environment, including the chroot environment.

Changing the install instructions in the packages of Chapter 6 to use DESTDIR seems like a reasonable thing to do to provide flexibility, but putting the actual command to use paco in every package would seem like a task that should be left to the user.

Looks like that's the only reasonable point for now. Thanks, bdubbs!

[bryan@linuxfromscratch.org]

Replying to spinal84:

Replying to 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 ​package management section in the book. Especially the "Some reasons why no package manager is mentioned in LFS or BLFS include:" part. :-) )

[randy@…]

At the risk of having to read a reply from Spinal (saying the same things that have been said in the previous 5 entries he's made on this ticket), I'm against adding paco to the book.

Reviewing the ticket, I can't tell which direction Dan is leaning, and Bruce is sitting on the fence without opinion (he said he could add DESTDIR but not paco commands, I think), but everyone else (Alex, Matt, Ag, Chris, Bryan) has commented that adding paco is undesireable.

So I'm confused as to Bruce's comment, "There seems to be a demand for this type of thing". The only person "demanding" anything is the originator of the ticket. That is one person. Nobody else that I can see has actually said, "yeah, good idea, let's do it". Seems everyone else other than Dan and Bruce who really didn't commit either way, are quite adament that it should *not* be added. I'm in that crowd.

And unless there is some new information added about paco that hasn't already been said, replying to my comments is not necessary as I feel very similar to the other guys who've listed very valid and legitimate reasons why it is not a good idea for LFS.

[bdubbs@…]

As Randy says, I'm on the fence. We could mention paco in section 6.3 "Package Management".

I do think that Chapter 6 needs to be updated to use DESTDIR. This would support several package management techniques.

I don't mind doing this but I would like to ask others to help identify any packages that do not play nicely with the DESTDIR methodology.

I'll note that this is a fairly major change in that it touches virtually all the packages in Chapter 6.

[Arthur Demchenkov]

I'm sorry. I didn't want to embroil you guys. I just wanted to make LFS book better. Forget about that ticket. Good luck!

[david_rr]

Hi there, I am David, the main developer of paco.

As Randy says, I see no reason to include any paco command explicity in the LFS book, because (apart from the reasons exposed above), it would break the phylosophy of building a non-bloated system.

Nevertheless, I'd like to point out that I have received many emails from LFS builders that are hapilly using paco, but they wonder why they have discovered it so late. That's because there's not any single reference to paco in LFS nor in BLFS. IMHO I think it would be very helpful for the LFS users to know at least that there exists a package management tool called paco that it is specially designed for LFS.

Moreover, I have seen that there's a section regarding package management in LFS. It exposes different package management techniques, and it also mentions some examples of package managers using each approach. I suggest to make just a little reference to paco in the section presenting the LD_PRELOAD approach. I thing paco is the only "serious" tool using this approach, apart from CheckInstall (which is far more complicated).

[alexander@…]

see also ticket #2073

[alexander@…]

Replying to randy@linuxfromscratch.org:

Reviewing the ticket, I can't tell which direction Dan is leaning, and Bruce is sitting on the fence without opinion (he said he could add DESTDIR but not paco commands, I think), but everyone else (Alex, Matt, Ag, Chris, Bryan) has commented that adding paco is undesireable.

Correction: I am only saying that adding explicit support for paco in its current form without alternatives is undesired. It is OK to mention it on the reworked package management page while saying that it targets only on easy uninstallation of packages, not deployment to multiple systems.

[dnicholson@…]

My opinion is that package management is crucial for anything more than a toy system. However, I think we either have to gloss over it like we currently do (because really supporting package management would open a whole can of worms), or take one system and embrace it.

So, I basically agree with Alexander and David (Rosal, the paco developer). I don't think we want to start adding the commands into the book for a particular package management system, but I think we could do a much better job explaining the current offerings and how they work.

I'd like to see paco featured in the LD_PRELOAD section. It's the quickest solution to any form of package management; even simpler and quicker to start using than the timestamp method.

I'd also like to see what a DESTDIR is and explain how it's used, rather than using it throughout the book. Installing to a DESTDIR in the book without doing anything else with those files doesn't benefit anyone (IMO).

[bdubbs@…]

I'd also like to see what a DESTDIR is and explain how it's used, rather than using it throughout the book. Installing to a DESTDIR in the book without doing anything else with those files doesn't benefit anyone (IMO).

I agree with the first sentence, but not the second. Installing to a DESTDIR allows all the commands of a build for a package to be done without being the root user. (I know in LFS Chapter 6 we are root all the time, but this creates a pattern that could be followed in BLFS.) It allows a user to inspect the files before installation, and it sets up a methodology that could be used for one of several package management methods, not just paco.

My current scripts generally look like:

PROGRAM=<package name and version>
DIR=`pwd`
LOG=$DIR/$PROGRAM.log.book
BUILDDIR=/tmp/<package name>

rm -rf $BUILDDIR
mkdir $BUILDDIR
cd $BUILDDIR

tar -xf $DIR/$PROGRAM.tar.?z*
cd $PROGRAM
{ time \
  {
    ./configure --prefix=/usr ...  &&
    make &&
    make DESTDIR=$BUILDDIR/install install  
  }
} 2>&1 | tee -a $LOG
   

As an aside, this puts all the build and installation files in one directory in /tmp that allows me to measure the build size for BLFS and check for what files and directories are created. Going one more step to store this data in one of several package management systems now becomes almost trivial.

I feel adding this type of flexibility to the book would be greatly beneficial to new users.

[dnicholson@…]

Replying to bdubbs@linuxfromscratch.org:

I agree with the first sentence, but not the second. Installing to a DESTDIR allows all the commands of a build for a package to be done without being the root user.

In the simple case that's correct, but there are a lot of things that only root can do, like run ldconfig. Likewise, there are certain things that can only be done on / like install-info to /usr/share/info/dir or setup gconf schemas.

What I'm really against, though, is putting the DESTDIR commands in without a detailed explanation of moving them from $DESTDIR to /. The last thing I want to happen is have someone bork their system because of this.

[randy@…]

Shouldn't this discussion be taking place on -dev? Most of the messages to this ticket are not going to -book because of the tight control of who may or may not post, so there's really nobody seeing this except for a few who happened to read one of the few -book messages.

Something as large as changing the build commands should be something that as many people as possible should be commenting on.

Additionally, I'm not a big fan of including DESTDIR in the build commands. Seems we could explain it, perhaps show an example and that would be enough. But doesn't really matter to me from an LFS standpoint. What bothers me is that BLFS installation methods would be different than LFS.

Sure, update LFS to use DESTDIR then update BLFS. Problem with that is it simply won't happen in BLFS. We can't even get package updates or bugs fixed right now due to lack of developer time (the occasional once-a-month package update notwithstanding).

[gerard@…]

Won't fix for now. This will need to be re-addressed in a more generic package manager discussion in the near future.