Date: Thu, 19 Aug 2010 20:08:15 -0700 From: Garrett Cooper <yaneurabeya@gmail.com> To: jhell <jhell@DataIX.net> Cc: bapt@FreeBSD.org, Florent Thoumie <flz@FreeBSD.org>, Julien Laffaye <jlaffaye@FreeBSD.org>, David Forsythe <dforsyth@FreeBSD.org>, Garrett Cooper <gcooper@FreeBSD.org>, Tim Kientzle <kientzle@FreeBSD.org>, Ivan Voras <ivoras@FreeBSD.org>, freebsd-ports@FreeBSD.org Subject: Re: what next for the pkg_install rewrite Message-ID: <A4FFBD88-8830-4BB3-8765-AC7BAB8AC91C@gmail.com> In-Reply-To: <4C6DE8DB.8010202@DataIX.net> References: <20100819143830.GJ35140@azathoth.lan> <AANLkTimY=FJas-oXkWwO07QtaD%2BGrLockgJ_SZQJ7UHM@mail.gmail.com> <AANLkTimhh2vOtXUb-frzWcZmANWyEC7oPtTgepzvOtSB@mail.gmail.com> <4C6DA0FA.7080203@DataIX.net> <AANLkTi=h_GdAFbZ2X0agCAtyLLiwNrMoLx_ZunhBBx2=@mail.gmail.com> <AANLkTinn4utHttMPsCN1GKp1dTPOdTJAtLgG3m8BfLgw@mail.gmail.com> <4C6DE8DB.8010202@DataIX.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org> =
wrote:
>>>> On 19/08/2010, jhell <jhell@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:
>>>>>>=20
>>>>>> ${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.
>>=20
>=20
> You may have misunderstood or maybe not the intention behind that =
file.
>=20
> 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.
>=20
> -- 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=3D16963 .
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.
>=20
> 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.
>=20
> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A4FFBD88-8830-4BB3-8765-AC7BAB8AC91C>