In the policy manual, section 7.5.1 "Overwriting files in other packages" it
says:
"However, if the overwriting package declares that it Replaces the one
containing the file being overwritten, then dpkg will replace the file from
the old package with that from the new. The file will no longer be
tisdagen den 12 november 2002 11.09 skrev Andrea Mennucc:
> can you post a copy of your debian/control file?
I have to come back with this and construct an example.
-- Karolina
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
When I run this, I get the following error messages. What does it mean?
Which file(s) are already existing?
$ dpkg-source -b noteedit-2.0.16 noteedit_2.0.16.orig.tar.gz
dpkg-source: building noteedit using existing noteedit_2.0.16.orig.tar.gz
tar: noteedit-2.0.16/doc/noteedit/afterCombine.png: Can
tisdagen den 12 november 2002 21.28 skrev Roger Leigh:
> It looks like all the files are pre-existing. Try running dpkg-source
> -b from another directory or renaming the noteedit-2.0.16 directory?
That might be the problem, so please bear me with some questions so that I get
this very clear to
tisdagen den 12 november 2002 21.28 skrev Roger Leigh:
> It looks like all the files are pre-existing. Try running dpkg-source
> -b from another directory or renaming the noteedit-2.0.16 directory?
... And then yet another question. When I get the following error message:
In file included from
Wednesday 13 November 2002 22.30 skrev Roger Leigh:
> The `clean' rule is run before the build (by dpkg-buildpackage), so I
> would do
>
> find . -name '*.moc' | xargs rm -f
>
> to remove the .moc files. If they can easily be regenerated, I would
> ask upstream to remove them from the tarball (bu
Wednesday 13 November 2002 12.18 skrev Paul Cupis:
> It can be modified. It should be unchanged. Being unchanged has beneifts
> including but not limited to allowing users to verify the original tgz with
> upstream and clearly showing (in the diff.gz) what changes were made during
> packaging. If
How do I include a binary file like a .png file in the diff?
I need to include a PNG file with the application icon, which is not
supplied in the upstreams tar.
-- Karolina
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tisdagen den 3 december 2002 09.32 skrev Karolina Lindqvist:
> How do I include a binary file like a .png file in the diff?
> I need to include a PNG file with the application icon, which is not
> supplied in the upstreams tar.
Sorry for that, that question was just answered
I have a problem with files in /etc
As I understand, they are marked as "conffiles". The problem is if such a file
is missing, it won't be reinstalled. How to tell the package system that this
file should be reinstalled if it is deleted?
i.e. The file is essential, and can't be missing.
This has
onsdagen den 8 januari 2003 18.57 skrev Raphael Hertzog:
> apt-get -o dpkg::options::="--force-confmiss"
>
> You can put it once for all in a file in /etc/apt/apt.conf.d/.
> Check man apt.conf for details.
That is the individual solution when the trouble is there. But is there no way
to make the
fredagen den 10 januari 2003 16.49 skrev Bob Hilliard:
> Policy prohibits overriding conffiles that have been changed by
> the admin. Deleting a file is considered changing it. One must
> assume that the admin deleted the file for a reason. Debian does not
> prevent users from shooting the
fredagen den 10 januari 2003 20.06 skrev Stephen Gran:
> I've seen this behavior occasionally on some of my boxes, and I wonder
> if the problem is that the newer version of a pckage has a conffile that
> the older version doesn't have. Hmmm . . not very clear. Like this:
>
> package-foo_1.2 con
The subject line says it all. I have a condition where apt-get refuses to
upgrade. How can I figure out exactly what apt-get does not like:
Here follows my example run. The reason I use a versioned install is just
because otherwise apt-get just refuses to consider the upgrade. This is a
problem
I have been inofficially packing KDE 3.1 since several months. I have also
packed a number of KDE 3.1 applications (47 different right now) together
with it. (But that is fast packing, without bug fixing, except for making
them build)
Now KDE 3.1 is going to make it into SID, so I was thinking
fredagen den 31 januari 2003 14.03 skrev Russell Coker:
> On Thu, 30 Jan 2003 20:04, Karolina Lindqvist wrote:
> > Any takers or suggestions?
>
> I'll sponsor you if no-one else does, particularly if you take kdm.
Thank you.
Unfortunately kdm is part of KDE, and can't
In the policy manual, section 7.5.1 "Overwriting files in other packages" it
says:
"However, if the overwriting package declares that it Replaces the one
containing the file being overwritten, then dpkg will replace the file from
the old package with that from the new. The file will no longer be
tisdagen den 12 november 2002 11.09 skrev Andrea Mennucc:
> can you post a copy of your debian/control file?
I have to come back with this and construct an example.
-- Karolina
When I run this, I get the following error messages. What does it mean?
Which file(s) are already existing?
$ dpkg-source -b noteedit-2.0.16 noteedit_2.0.16.orig.tar.gz
dpkg-source: building noteedit using existing noteedit_2.0.16.orig.tar.gz
tar: noteedit-2.0.16/doc/noteedit/afterCombine.png: Can
tisdagen den 12 november 2002 21.28 skrev Roger Leigh:
> It looks like all the files are pre-existing. Try running dpkg-source
> -b from another directory or renaming the noteedit-2.0.16 directory?
That might be the problem, so please bear me with some questions so that I get
this very clear to
tisdagen den 12 november 2002 21.28 skrev Roger Leigh:
> It looks like all the files are pre-existing. Try running dpkg-source
> -b from another directory or renaming the noteedit-2.0.16 directory?
... And then yet another question. When I get the following error message:
In file included from
Wednesday 13 November 2002 22.30 skrev Roger Leigh:
> The `clean' rule is run before the build (by dpkg-buildpackage), so I
> would do
>
> find . -name '*.moc' | xargs rm -f
>
> to remove the .moc files. If they can easily be regenerated, I would
> ask upstream to remove them from the tarball (bu
Wednesday 13 November 2002 12.18 skrev Paul Cupis:
> It can be modified. It should be unchanged. Being unchanged has beneifts
> including but not limited to allowing users to verify the original tgz with
> upstream and clearly showing (in the diff.gz) what changes were made during
> packaging. If
How do I include a binary file like a .png file in the diff?
I need to include a PNG file with the application icon, which is not
supplied in the upstreams tar.
-- Karolina
tisdagen den 3 december 2002 09.32 skrev Karolina Lindqvist:
> How do I include a binary file like a .png file in the diff?
> I need to include a PNG file with the application icon, which is not
> supplied in the upstreams tar.
Sorry for that, that question was just answered
I have a problem with files in /etc
As I understand, they are marked as "conffiles". The problem is if such a file
is missing, it won't be reinstalled. How to tell the package system that this
file should be reinstalled if it is deleted?
i.e. The file is essential, and can't be missing.
This has
onsdagen den 8 januari 2003 18.57 skrev Raphael Hertzog:
> apt-get -o dpkg::options::="--force-confmiss"
>
> You can put it once for all in a file in /etc/apt/apt.conf.d/.
> Check man apt.conf for details.
That is the individual solution when the trouble is there. But is there no way
to make the
fredagen den 10 januari 2003 16.49 skrev Bob Hilliard:
> Policy prohibits overriding conffiles that have been changed by
> the admin. Deleting a file is considered changing it. One must
> assume that the admin deleted the file for a reason. Debian does not
> prevent users from shooting the
fredagen den 10 januari 2003 20.06 skrev Stephen Gran:
> I've seen this behavior occasionally on some of my boxes, and I wonder
> if the problem is that the newer version of a pckage has a conffile that
> the older version doesn't have. Hmmm . . not very clear. Like this:
>
> package-foo_1.2 con
The subject line says it all. I have a condition where apt-get refuses to
upgrade. How can I figure out exactly what apt-get does not like:
Here follows my example run. The reason I use a versioned install is just
because otherwise apt-get just refuses to consider the upgrade. This is a
problem
I have been inofficially packing KDE 3.1 since several months. I have also
packed a number of KDE 3.1 applications (47 different right now) together
with it. (But that is fast packing, without bug fixing, except for making
them build)
Now KDE 3.1 is going to make it into SID, so I was thinking
fredagen den 31 januari 2003 14.03 skrev Russell Coker:
> On Thu, 30 Jan 2003 20:04, Karolina Lindqvist wrote:
> > Any takers or suggestions?
>
> I'll sponsor you if no-one else does, particularly if you take kdm.
Thank you.
Unfortunately kdm is part of KDE, and can't
32 matches
Mail list logo
