On Mon, 2011-07-18 at 14:19 +0200, Paul Wise wrote:
> On Sun, Jul 17, 2011 at 1:04 AM, Peter Samuelson wrote:
>
> > - Treat the file as though it were shipped in the package directly.
> > This means it is removed on package upgrade, as well as on package
> > removal. This is very straightforwar
On Sun, Jul 17, 2011 at 1:04 AM, Peter Samuelson wrote:
> - Treat the file as though it were shipped in the package directly.
> This means it is removed on package upgrade, as well as on package
> removal. This is very straightforward (append the filename to
> /var/lib/dpkg/info/{foo}.list), b
[Roger Leigh]
> By registering the file as I create it, I completely avoid the
> breakage potential of complex and poorly-tested postrm logic--it's
> completely removed. It also means that other packages can't
> arbitrarily overwrite it. It would certainly be very useful for
> e.g. generated fil
On Sat, Jul 16, 2011 at 08:32:46PM +0100, Christopher Baines wrote:
> On Sat, 2011-07-16 at 17:12 +0200, Paul Wise wrote:
> > On Sat, Jul 16, 2011 at 4:48 PM, Peter Samuelson wrote:
> >
> > > It would be useful in any number of situations to be able
> > > to "register" a file with dpkg: tell dpkg
On Sat, 2011-07-16 at 17:12 +0200, Paul Wise wrote:
> On Sat, Jul 16, 2011 at 4:48 PM, Peter Samuelson wrote:
>
> > It would be useful in any number of situations to be able
> > to "register" a file with dpkg: tell dpkg that a given package owns a
> > given file, so that it is automatically remove
On Sat, Jul 16, 2011 at 4:48 PM, Peter Samuelson wrote:
> It would be useful in any number of situations to be able
> to "register" a file with dpkg: tell dpkg that a given package owns a
> given file, so that it is automatically removed when the package is
> removed or upgraded. I can see this b
[Christopher Baines]
> I would consider the best solution to be a mixture of the two, so the
> symbolic package handles fetching the data, but then tells dpkg what
> files its putting where.
I don't really care that much about huge data packages, but this jumped
out at me. It would be useful in
On Sat, 16 Jul 2011 at 01:31:21 +0200, Arno Töll wrote:
> On 16.07.2011 00:20, Christopher Baines wrote:
> > The actual package would just contain the rules and checksums for the
> > files it tries to fetch, but not the data itself
>
> just as a random alternative idea (where other people may judg
On Fri, 2011-07-15 at 22:32 +, The Fungi wrote:
> On Fri, Jul 15, 2011 at 11:20:09PM +0100, Christopher Baines wrote:
> [...]
> > Any thoughts, or have I found a non-existent problem?
>
> A very-existent problem (the scientific package maintainers deal
> with this at least as much as the games
On Sat, 2011-07-16 at 01:31 +0200, Arno Töll wrote:
> Hi Christopher,
>
> On 16.07.2011 00:20, Christopher Baines wrote:
> > The actual package would just contain the rules and checksums for the
> > files it tries to fetch, but not the data itself, I think of this as a
> > symbolic package. This a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Christopher,
On 16.07.2011 00:20, Christopher Baines wrote:
> The actual package would just contain the rules and checksums for the
> files it tries to fetch, but not the data itself, I think of this as a
> symbolic package. This approach in my opi
On Fri, Jul 15, 2011 at 11:20:09PM +0100, Christopher Baines wrote:
[...]
> Any thoughts, or have I found a non-existent problem?
A very-existent problem (the scientific package maintainers deal
with this at least as much as the games package maintainers from
what I gather). It's come up a lot ove
Hello All,
I currently have two packages in the archive, one small ant related
package (ant-contrib-cpptasks) and a FlightGear related package (fgrun).
But its the FlightGear packaging I want to talk about.
For those of you that have yet to enjoy playing with FlightGear, its a
very flexible and
13 matches
Mail list logo
