On Fri August 11 2006 04:51, Ian Jackson wrote:
> Bruce Sass writes ("Re: Silly Packaging Problem"):
> > "files" and "size" accommodate the desire to include generated or
> > packageless files and their size (if knowable) in the dpkg DB.
>
> This
Bruce Sass <[EMAIL PROTECTED]> writes:
> On Thu August 10 2006 10:16, martin f krafft wrote:
>> also sprach Goswin von Brederlow
> <[EMAIL PROTECTED]> [2006.08.10.1647 +0100]:
>> > How about allowing conffiles to list files that are generated at
>> > install time and are not included in the deb?
martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Goswin von Brederlow <[EMAIL PROTECTED]> [2006.08.10.1647 +0100]:
>> How about allowing conffiles to list files that are generated at
>> install time and are not included in the deb?
>
> You can, but then you run up against policy. You are
Bruce Sass a écrit :
> I will be so bold as to suggest...
>
> Synopsis: update-package [options]
>
> update-package [options] --add-files=
> update-package [options] --remove-files=
> update-package [options] --size=
> update-package [options] --field=::
>
> Commands:
[...]
> Options:
> -
Bruce Sass writes ("Re: Silly Packaging Problem"):
> "files" and "size" accommodate the desire to include generated or
> packageless files and their size (if knowable) in the dpkg DB.
This is a bad idea. dpkg maintains these lists of files not primarily
fo
On Thu August 10 2006 16:20, martin f krafft wrote:
> also sprach Bruce Sass <[EMAIL PROTECTED]> [2006.08.10.2237 +0100]:
> > No point setting oneself up for bugs if it is not necessary.
> >
> > The script wouldn't determine anything, it would simply append
> > paths to the package's list of paths.
On Thu, Aug 10, 2006 at 06:35:03PM -0400, peek wrote:
> place. It just seems a little cleaner: you could query dpkg for what
> package *every* file came from -- no files left out; and you don't
what about rotated log files? pid files? lock files? misc stuff
in /var/cache?
that's not to bash th
Bruce Sass wrote:
An "update-package" command, run at install time by the maintainer's
scripts right after file generation succeeds, would head off potential
problems with synchronization that are outside of the Maintainer's
control (e.g., DEBIAN/dynfiles containing incorrectly generated paths
sean finney wrote:
On Thu, Aug 10, 2006 at 11:01:30AM +0100, martin f krafft wrote:
No, at least not for /etc. You could install the file, the overwrite
it, but files installed to /etc by dpkg are conffiles and those must
not be touched programmatically, according to policy.
i think a
also sprach Bruce Sass <[EMAIL PROTECTED]> [2006.08.10.2237 +0100]:
> No point setting oneself up for bugs if it is not necessary.
>
> The script wouldn't determine anything, it would simply append paths to
> the package's list of paths. The Maintainer would need to call the
> script "right afte
On Thu August 10 2006 15:10, martin f krafft wrote:
> also sprach Bruce Sass <[EMAIL PROTECTED]> [2006.08.10.2124 +0100]:
> > An "update-package" command, run at install time by the
> > maintainer's scripts right after file generation succeeds, would
> > head off potential problems with synchroniza
also sprach Bruce Sass <[EMAIL PROTECTED]> [2006.08.10.2124 +0100]:
> An "update-package" command, run at install time by the maintainer's
> scripts right after file generation succeeds, would head off potential
> problems with synchronization that are outside of the Maintainer's
> control (e.g.
On Thu August 10 2006 13:13, martin f krafft wrote:
> also sprach Bruce Sass <[EMAIL PROTECTED]> [2006.08.10.1959 +0100]:
> > Such a utility would need to be shipped with dpkg, a 3rd party or
> > random DD implementing it would be silly for anything but local
> > consumption.
> >
> > Is that the on
also sprach Bruce Sass <[EMAIL PROTECTED]> [2006.08.10.1959 +0100]:
> Such a utility would need to be shipped with dpkg, a 3rd party or random
> DD implementing it would be silly for anything but local consumption.
>
> Is that the only problem?
If dpkg knew how to track files it did not directly
On Thu August 10 2006 12:40, martin f krafft wrote:
> also sprach Bruce Sass <[EMAIL PROTECTED]> [2006.08.10.1925 +0100]:
> > Would updating /var/lib/dpkg/info/*.list files without touching the
> > appropriate Installed-Size: field be OK?
>
> Definitely not. /var/lib/dpkg is the domain of dpkg. Do
also sprach Bruce Sass <[EMAIL PROTECTED]> [2006.08.10.1925 +0100]:
> Would updating /var/lib/dpkg/info/*.list files without touching the
> appropriate Installed-Size: field be OK?
Definitely not. /var/lib/dpkg is the domain of dpkg. Do not go
there. You must not even assume that /var/lib/dpkg/in
On Thu August 10 2006 10:16, martin f krafft wrote:
> also sprach Goswin von Brederlow
<[EMAIL PROTECTED]> [2006.08.10.1647 +0100]:
> > How about allowing conffiles to list files that are generated at
> > install time and are not included in the deb?
>
> You can, but then you run up against policy
also sprach Goswin von Brederlow <[EMAIL PROTECTED]> [2006.08.10.1647 +0100]:
> How about allowing conffiles to list files that are generated at
> install time and are not included in the deb?
You can, but then you run up against policy. You are not allowed to
touch a conffile with a script.
--
sean finney <[EMAIL PROTECTED]> writes:
> On Thu, Aug 10, 2006 at 11:01:30AM +0100, martin f krafft wrote:
>> No, at least not for /etc. You could install the file, the overwrite
>> it, but files installed to /etc by dpkg are conffiles and those must
>> not be touched programmatically, according t
On Thu, Aug 10, 2006 at 11:01:30AM +0100, martin f krafft wrote:
> No, at least not for /etc. You could install the file, the overwrite
> it, but files installed to /etc by dpkg are conffiles and those must
> not be touched programmatically, according to policy.
i think a better solution (and one
also sprach Michael S. Peek <[EMAIL PROTECTED]> [2006.08.09.1322 +0100]:
> It seems that Debian doesn't care about keeping up with files
> created dynamically via install scripts. For instance, I can type
> 'dpkg -S /etc/papersize', and I get back 'dpkg: /etc/papersize not
> found.'
Yes, /etc/pap
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8 Aug 2006, at 10:48 pm, martin f krafft wrote:
also sprach Michael S. Peek <[EMAIL PROTECTED]> [2006.08.08.2239
+0100]:
The next time there's an upgrade for courier-authdaemon, won't it
overwrite my version of /etc/courier/authdaemonrc with i
martin f krafft wrote:
also sprach Michael S. Peek <[EMAIL PROTECTED]> [2006.08.08.2239 +0100]:
The next time there's an upgrade for courier-authdaemon, won't it
overwrite my version of /etc/courier/authdaemonrc with it's own?
No way. Packages must *never* overwrite your files in /etc
On Tue, Aug 08, 2006 at 05:39:48PM -0400, Michael S. Peek wrote:
[...]
> The next time there's an upgrade for courier-authdaemon, won't it
> overwrite my version of /etc/courier/authdaemonrc with it's own? I
> thought that was the whole reason for diversions in the first place, but
> if diversi
also sprach Michael S. Peek <[EMAIL PROTECTED]> [2006.08.08.2239 +0100]:
> The next time there's an upgrade for courier-authdaemon, won't it
> overwrite my version of /etc/courier/authdaemonrc with it's own?
No way. Packages must *never* overwrite your files in /etc.
> Is this kind of thing addre
Thanks for the help, Martin.
martin f krafft wrote:
also sprach Michael S. Peek <[EMAIL PROTECTED]> [2006.08.08.2124 +0100]:
2) I then divert this file.
Diversions of conffiles are not supported. Check that
/etc/courier/authdaemonrc is not a conffile. If it is, you could
easily lose
also sprach Michael S. Peek <[EMAIL PROTECTED]> [2006.08.08.2124 +0100]:
> 2) I then divert this file.
Diversions of conffiles are not supported. Check that
/etc/courier/authdaemonrc is not a conffile. If it is, you could
easily lose data in my experience.
> 1) I check for the presence of /etc/co
Hello all,
I hope I've got the right list. If not, I appologize; just point the
way and I'll take my question to the proper list.
I'm attempting to write a debian package for our site that installs
configuration files specific to our needs. I'm not a *complete* n00b --
I've written dozens
28 matches
Mail list logo
