what next for the pkg_install rewrite

[Garrett Cooper]

On Aug 19, 2010, at 7:30 PM, jhell wrote:

> On 08/19/2010 21:26, Garrett Cooper wrote:
>> On Thu, Aug 19, 2010 at 3:10 PM, Ivan Voras <ivoras at freebsd.org> wrote:
>>>> On 19/08/2010, jhell <jhell at dataix.net> wrote:
>>>>>>      Adding to this I would like to see a central database created for
>>>>>> packages that have been removed like in Slackware Linux. They keep a
>>>>>> file in /var/log/preserved_packages with a flat text format with the
>>>>>> file name looking like:
>>>>>> 
>>>>>> ${PORTNAME}-${PORTVERSION}${PORTREVISION}-`date +%Y%m%d%H%M%S`
>> Please no. We need another ad hoc text format like we need holes in our head.
>> 
> 
> You may have misunderstood or maybe not the intention behind that file.
> 
> 	This is just simply a log file of the transactions that were performed
> upon package deletion and nothing more but just a way for the user to
> look back and say "HEY! how did that get there!." or "where in the
> ``jhell'' did that file come from!" that they can simply grep the
> package removal logs to find out.
> 
>  -- Shameless plug with my email name put in for humor.

:)

> 	It is also really handy if you remove some packages that somehow the
> depends had been messed up and later on your having a problem with a
> missing lib, easy enough to grep the removal logs to find out what
> package held that file. Especially useful if you only use binary packages.

This is part of the request that someone was making for a feature like Gentoo's world file on the forums: http://forums.freebsd.org/showthread.php?t=16963 .

Personally it's one of the takeaways I like about Gentoo's portage system because it's easy to track what I as a user installed manually, and hence, it's easy to track what can be removed (instead of using pkg_cutleaves) if we have a `emerge -C` (package dependency [dist]clean equivalent). It also makes it easier for admins to mass install packages on multiple machines using a smaller `distroot' install binary base, so all I would have to do is:

1. Install prebuilt version of FreeBSD with sysinstall / ad hoc installer method.
2. Say, pkg_add <install all, force options>
3. Do whatever I need to do to configure the machine.

Done.

That would make system administration really easy and slick, and would improve the setup process for corporations that build on a static FreeBSD base for several releases and have varying packages for several bits. I know if my group did it, things wouldn't be such a mess..

By the way... /var/lib/portage/world is a simple text file composed line by line like:

<pkg-origin-a>
<pkg-origin-b>

i.e.

devel/gcc46
lang/python26
www/firefox36

etc. Simple and easy to understand, and easy to modify :).

> 	There is a lot of information that can be logged, especially with '-v',
> I personally do not think we or anyone for that matter should pass up
> that opportunity to make sure the information is collected rather than
> leaving it up to the user to redirect or script(1) the output every time
> which they would still or should be able to do.
> 
> 	Another approach that I have not seen talked about here is a proposed
> directory layout. I think before 'unless I missed it' that someone jumps
> into this, some standards & goals should be made and made quite loudly
> as to attract as much public opinion and suggestions as possible for
> what works, what does not & what people would like to see.
> 
> 	Something of this magnitude like changing packaging databases and
> directory structures and all that involved needs a central place and a
> clear, clean plan to be developed properly. I personally do not see this
> list anymore as a proper place to discuss it. packaging@ list request ?
> so this can all be centralized.

I agree that it's high time that a freebsd-packaging@ list be created. sysinstall has its own list now -- we should have one for the packaging software too :).

> PS: I have been toying with the idea of the directory layout just for
> spurring thoughts of others. http://bit.ly/aNLhNU but until there is a
> central place for these things it does not mean much.


I think that you're adding unnecessary complexity to the overall issue. It really doesn't make sense for me to install packages that aren't available for my architecture for one (in particular today), unless you were thinking of serving up this data on an NFS server, but even then it doesn't make sense because almost all of these files are hardcoded to exist at ${LOCALBASE} when built as ports, so setting it to another location would be problematic. Other things would need to be done before you could get to this stage.

Also, many of the ports installed are prefixed with the package name, which is different for multiple ports. Example:

$ ls /var/db/pkg/python*
python-2.6,2/     python26-2.6.5_1/ python31-3.1.2_1/

Having a concept of multiple versions in ports would require a major overhaul to get things to work in a Gentoo like method, and I'm not sure how many people would be particularly keen in doing this (especially when there are name collisions in installed package files).

Oh, and there was the tunable packages idea (what I originally called `fat packages', but Julien has done work on `fat packages', so I'll yield to that usage :P), where the contents of packages could be tuned according to config options requested by end-users and/or set by package maintainers, to get the granularity of distributing orthogonal features for packages, like xorg-server-hal-support xorg-server-no-hal-support (or whatever the proper title would be).

The emphasis that Florent made too was to remove crud in pkg_install and libpkg and get things down to more of a library form so we could develop thin wrappers above pkg_install with logical functions (like apt-get, yum, etc does with fetching, whereas rpm does with installation, etc), instead of maintaining pkg_install the way it is today.

Thanks,
-Garrett