On Mon, Oct 05 2009, Goswin von Brederlow wrote:
> Is the Packages.gz file then in violation of my packages license? It
> doesn't come with a copy of the GPL as required by my software. :)
In a narrow sense, this is also an argument you may make about
any .deb whose license belongs in /
Russ Allbery writes:
> Emilio Pozuelo Monfort writes:
>> Goswin von Brederlow wrote:
>
>>> Do you happen to know the chapter/section where that is said?
>
>>> Note that "12.7 Changelog files" does not require a
>>> /usr/share/doc/changelog for native packages.
>
>> 2.3. Copyright considerations
Emilio Pozuelo Monfort writes:
> Goswin von Brederlow wrote:
>> Russ Allbery writes:
>>
>>> Goswin von Brederlow writes:
>>>
Dpkg has the ability to vanish empty packages. A dummy package should
be completly empty and not even contain a /usr/share/doc/.
>>> Such a package is explicit
Emilio Pozuelo Monfort writes:
> Goswin von Brederlow wrote:
>> Do you happen to know the chapter/section where that is said?
>> Note that "12.7 Changelog files" does not require a
>> /usr/share/doc/changelog for native packages.
> 2.3. Copyright considerations
> -
On Mon, Sep 28, 2009 at 11:04:25AM +0200, Goswin von Brederlow wrote:
> Ok, so one would need to have at least an empty directory (say /usr)
> in the package for it to disapear? Why the distinction?
Because an empty package is valid (doesn't equivs create these?), and having
Replaces: take effect
Goswin von Brederlow wrote:
> Russ Allbery writes:
>
>> Goswin von Brederlow writes:
>>
>>> Dpkg has the ability to vanish empty packages. A dummy package should
>>> be completly empty and not even contain a /usr/share/doc/.
>> Such a package is explicitly forbidden by Debian Policy. You need t
Russ Allbery writes:
> Goswin von Brederlow writes:
>
>> Dpkg has the ability to vanish empty packages. A dummy package should
>> be completly empty and not even contain a /usr/share/doc/.
>
> Such a package is explicitly forbidden by Debian Policy. You need to
> propose a Policy change if you
Guillem Jover writes:
> On Wed, 2009-09-23 at 10:51:50 +0200, Goswin von Brederlow wrote:
>> Magnus Holmgren writes:
>> > When a binary package is renamed or split, as well as if several packages
>> > are
>> > merged under a new name, transitional packages are normally created, which
>> > dep
On Sun, Sep 27, 2009 at 06:11:13PM +0200, Andreas Metzler wrote:
> I always thought dummy transitional packages were supposed to be in
> section oldlibs anyway.
According to the archive section description, that section is just for
transition *libraries* (as the name hints).
--
Stefano Zacchirol
On Sun, Sep 27, 2009 at 07:22:27PM +0200, Vincent Danjean wrote:
> Recognizing transitional packages is only a small part of the problem.
Agreed. As discussed in my post, that's the part of the problem which I
was trying to address.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ U
On Sun, Sep 27, 2009 at 04:30:50PM +0200, Stefano Zacchiroli wrote:
>
> - Status quo: grepping for "transitional package" in package
> descriptions
>
Transitional packages are often not defined as such in description.
Too unsafe rely on keyword such as transitional, dummy, what else.
This is s
Stefano Zacchiroli wrote:
> I see various ways of enabling such recognition:
Recognizing transitional packages is only a small part of the problem.
You also need to 'move' the 'non-automatic' flags to another package
if needed. And I'm not sure there is currently enough information in
(transitiona
In gmane.linux.debian.devel.general Stefano Zacchiroli wrote:
[...]
> - Archive section (i.e. Frankie's proposal): would ftp-master (Cc-ed)
> be willing to pursue that road?
[...]
I always thought dummy transitional packages were supposed to be in
section oldlibs anyway.
cu andreas
--
To UNS
On Thu, Sep 24, 2009 at 05:37:03PM +0200, Francesco P. Lovergine wrote:
> What about moving those packages under a transitional Section in the
> archive? That would allow users to easily detect and remove them
> after dist-upgrades for instance, and it would also allow maintainers
> to mark proper
On Thu, Sep 17, 2009 at 11:52:23PM +0200, Magnus Holmgren wrote:
> When a binary package is renamed or split, as well as if several packages are
> merged under a new name, transitional packages are normally created, which
> depend on the new packages, which in turn Replaces and Conflicts with, an
On Wed, 2009-09-23 at 10:51:50 +0200, Goswin von Brederlow wrote:
> Magnus Holmgren writes:
> > When a binary package is renamed or split, as well as if several packages
> > are
> > merged under a new name, transitional packages are normally created, which
> > depend on the new packages, which
Goswin von Brederlow writes:
> Dpkg has the ability to vanish empty packages. A dummy package should
> be completly empty and not even contain a /usr/share/doc/.
Such a package is explicitly forbidden by Debian Policy. You need to
propose a Policy change if you want to do this. I believe it wa
On Sun, 20 Sep 2009, Pierre Habouzit wrote:
> So while I dismissed your idea at first thinking you wanted to make it a
> dpkg thing, now that I understand that you rather want it to be an /apt/
> one, it makes really more sense to me.
I also believe that it's something that would be nice to have.
Magnus Holmgren writes:
> When a binary package is renamed or split, as well as if several packages are
> merged under a new name, transitional packages are normally created, which
> depend on the new packages, which in turn Replaces and Conflicts with, and
> possibly Provides, the old package
Pierre Habouzit writes:
> On Thu, Sep 17, 2009 at 11:52:23PM +0200, Magnus Holmgren wrote:
> Note that transitional packages are seamless for users. When users has
> foo in $stable, and foo gets renamed into bar in $stable +1, then there
> is that:
>
> $stable: package foo
> $stable + 1: foo Depe
Magnus Holmgren writes:
> When a binary package is renamed or split, as well as if several packages are
> merged under a new name, transitional packages are normally created, which
> depend on the new packages, which in turn Replaces and Conflicts with, and
> possibly Provides, the old package
On Sun, Sep 20, 2009 at 06:16:52PM +0200, Magnus Holmgren wrote:
> On lördagen den 19 september 2009, Pierre Habouzit wrote:
> > There is one point in having the transitional package: it ensures that
> > no package does try to take "foo" as a package name in $stable + 1 which
> > would then in turn
On lördagen den 19 september 2009, Pierre Habouzit wrote:
> On Thu, Sep 17, 2009 at 11:52:23PM +0200, Magnus Holmgren wrote:
> > When a binary package is renamed or split, as well as if several packages
> > are merged under a new name, transitional packages are normally created,
> > which depend on
Anton Piatek wrote:
> 2009/9/19 Eugene V. Lyubimkin :
>> Anton Piatek wrote:
This should really be done by the package management, not by the user.
>>> It sounds like you are describing the following:
> $stable: package foo
>>> manually installed
> $stable + 1: foo Depends bar, bar {re
2009/9/19 Eugene V. Lyubimkin :
> Anton Piatek wrote:
>>> This should really be done by the package management, not by the user.
>>
>> It sounds like you are describing the following:
$stable: package foo
>> manually installed
$stable + 1: foo Depends bar, bar {replaces foo, provides foo,
Anton Piatek wrote:
>> This should really be done by the package management, not by the user.
>
> It sounds like you are describing the following:
>>> $stable: package foo
> manually installed
>>> $stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts
>>> foo}
> foo should now b
2009/9/19 Sven Joachim :
> On 2009-09-19 21:18 +0200, Pierre Habouzit wrote:
>
>> Note that transitional packages are seamless for users. When users has
>> foo in $stable, and foo gets renamed into bar in $stable +1, then there
>> is that:
>>
>> $stable: package foo
>> $stable + 1: foo Depends bar,
On 2009-09-19 21:18 +0200, Pierre Habouzit wrote:
> Note that transitional packages are seamless for users. When users has
> foo in $stable, and foo gets renamed into bar in $stable +1, then there
> is that:
>
> $stable: package foo
> $stable + 1: foo Depends bar, bar {replaces foo, provides foo,
On Thu, Sep 17, 2009 at 11:52:23PM +0200, Magnus Holmgren wrote:
> When a binary package is renamed or split, as well as if several packages are
> merged under a new name, transitional packages are normally created, which
> depend on the new packages, which in turn Replaces and Conflicts with, an
Magnus Holmgren wrote:
> On fredagen den 18 september 2009, Eugene V. Lyubimkin wrote:
>> Magnus Holmgren wrote:
>>> I propose a new control field called e.g. Supersedes that will provide
>>> the same semantics. In its simplest form, a renamed package will declare
>>> that it Supersedes the old pac
On fredagen den 18 september 2009, Eugene V. Lyubimkin wrote:
> Magnus Holmgren wrote:
> > I propose a new control field called e.g. Supersedes that will provide
> > the same semantics. In its simplest form, a renamed package will declare
> > that it Supersedes the old package name. That will be co
Magnus Holmgren wrote:
> When a binary package is renamed or split, as well as if several packages are
> merged under a new name, transitional packages are normally created, which
> depend on the new packages, which in turn Replaces and Conflicts with, and
> possibly Provides, the old packages.
When a binary package is renamed or split, as well as if several packages are
merged under a new name, transitional packages are normally created, which
depend on the new packages, which in turn Replaces and Conflicts with, and
possibly Provides, the old packages. I find those dummy packages as
33 matches
Mail list logo
