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 <ivo...@freebsd.org> wrote:
>>>> On 19/08/2010, jhell <jh...@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_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
