Re: debian-devel-digest Digest V2007 #198
debian-devel-digest-request@lists.debian.org wrote:
------------------------------------------------------------------------
debian-devel-digest Digest Volume 2007 : Issue 198
Today's Topics:
Draft spec for new dpkg "triggers" f [ Ian Jackson <iwj@ubuntu.com> ]
Some fairly useless comments by me about dpkg features (sorry).
To understand your specification sufficiently I would need to read it
through a few more times at least as it seems quite involved.
I use the current version of DPKG but have never written a 'package'
from scratch just built others.
I have experience of writing 'packages' from scratch on the Ms
platforms. The WixMSI. packager that I used had a fair number of
features but my main concern when packaging applications was that I did
not have to waste time learning lots of things just to put it in the
best format and I did not need to know much about eventualities on
target systems.
Looking at what you have written I suppose it is not really a low level
enough 'comment'? But for me, it is important to know that it is not
difficult and needy of much maintenance from version to version of a
program and perhaps more importantly diversion to diversion where
platforms are concerned.
It occurred to me that something which has always caused me a little
concern on Linux is the difference in file locations between
distributions and even branches. I have trouble keeping track of files
on Linux where in the last years of using Windows at home I used to
actually delete large chunks of the operating systems files just because
I knew they were not required for what I wanted. Obviously it is not a
fair comparison because if Linux included well known 'generally useless'
files then I would be doing the same but I have to say it seems a little
trickier deleting files in case they are there for compatibility
purposes or some such thing.
No doubt there are programs out there that I have not heard of that are
able to clean and tidy symlinks and obsoleted not required files but
personally I would feel far better if the package system did this not
some script or Windows esque package with a fancy title like "SymKiller"
or some such thing.
Sometimes I find it difficult to keep track of what is going on with
requirements installed and requirements not removed on de install of the
same. Typically this happens most when I am performing dist-upgrade or
upgrade using apt. After two months without an upgrade it is not easy to
remember some package that need not have been there had it not been for
a package that is now to be de installed post an upgrade that cannot
retain or no longer requires that previously required package.
Probably the 'response to this response' is that I should learn better
how to use APT/DPKG and also be more responsible?
Amongst the other things done with computers it would be better if there
were some way to simplify this.
The only thing that comes to mind is some sort of templates mechanism,
or rather? install lists.
This from the thinking that generally when I set a system up I install
particular packages so if I could run a cleanup that reverted back to
these packages and displayed everything else that was not really part of
the list so that I could review why it was there and then remove it.
Other concepts for this are that I often use networked computers and on
a theme of the package manager it might be useful from my point of view
to manage the packages for a network segment and decide which computer
is which.
For instance, postfix is on server a which is stable. The config files
are another matter perhaps on an share. Some problem turns up so I
decide to move postfix to server b. dpkg --migrate or dpkg --move mta
--source server a --target server b. or some such nonsense?
--migrate might copy across configuration files (which are links to the
network share anyway) while sending a purge to server a after server b
has reported up and running.
--move might try to just move the binaries or sources complete with
configurations to the new server.
then for multiple distribution networks or specialised setups of debian
such as on servers with LVM on many shares consider:
for --migrate the ability of dpkg to relocate the configuration files
being handed over (if the locations were for some reason different) is
one issue.
for --move then placement of everything.
I am not sure really if there is much advantage to this or how complex
it would be to integrate into the design but I hoped it might be useful
to read for someone,
Reply to: