Christian Schwarz <[EMAIL PROTECTED]> writes:
> I still think that it's not our job to "judge" which packages are fine and
> which are not. What we can probably do, is to set up a web page which
> explains packages from third parties and describes their problems, but
> "hardcoded" a list into dpkg
On 28 Nov 1997, Rob Browning wrote:
> Christian Schwarz <[EMAIL PROTECTED]> writes:
>
> > I think such a "blacklist" goes too far (cf. the current discussion on
> > debian-private about "censored" packages). I don't think we should
> > maintain such a list.
> >
> > However, we should probably im
Hamish Moffatt wrote:
>
> At the risk of starting another flamewar, providing a KDE
> package that installs in /opt is an obvious violation of debian
> policy, which I assume is why Andreas does his own. Although
> Andreas encourages us not to get the KDE people off-side,
> sometimes it wouldn't h
Christian Schwarz <[EMAIL PROTECTED]> writes:
> I think such a "blacklist" goes too far (cf. the current discussion on
> debian-private about "censored" packages). I don't think we should
> maintain such a list.
>
> However, we should probably implement something like the "Origin:" field.
> With
[Please note, that this discussion has just been resolved--see the other
mails. I just want to comment on this mail generally.]
On Fri, 28 Nov 1997, Andreas Jellinghaus wrote:
> > I thought that policy required discussion, not just notification.
>
> thanks for telling me ! i looked at the poli
On 28 Nov 1997, Rob Browning wrote:
[snip]
> This situation makes me think we might eventually want a database
> which can be used to list "problem" packages. dpkg would refuse to
> install any packaage whose name glob-matched a line in the database
> unless the user uses something like --force-p
Hamish Moffatt <[EMAIL PROTECTED]> writes:
>
>On Fri, Nov 28, 1997 at 02:41:13PM +0100, Andreas Jellinghaus wrote:
[not sure who wrote this, I presume it was Hamish Moffat]
>> > We are still supporting their packages in the sense
>> > that we support their installation. Should any package
>> > re
Christian Schwarz <[EMAIL PROTECTED]> writes:
> Now to the critical point: I don't think it's our job to change our
> packages in such a way that some third party (hear: KDE) can replace them.
> In fact, I think it's the third party's job to fix _their_ packages so
> they integrate into the Debian
On Fri, 28 Nov 1997, Hamish Moffatt wrote:
> At the risk of starting another flamewar, providing a KDE
> package that installs in /opt is an obvious violation of debian
> policy, which I assume is why Andreas does his own. Although
> Andreas encourages us not to get the KDE people off-side,
> some
Hello everybody!
I must say I don't like the course of this discussion. It looks like this
will eventually turn into yet-another flame war. To prevent this, please
let us stick to the facts and forget about all `wrong assumptions,'
`prejudices,' etc.
Note, that the topic of this discussion is v
On Fri, Nov 28, 1997 at 02:46:19PM +0100, Andreas Jellinghaus wrote:
> > I thought that policy required discussion, not just notification.
>
> thanks for telling me ! i looked at the policy :
> ... (using and not using virtual packages) ...
> They must not use virtual package names (except private
On Fri, Nov 28, 1997 at 02:41:13PM +0100, Andreas Jellinghaus wrote:
> > We are still supporting their packages in the sense
> > that we support their installation. Should any package
> > reference packages that aren't available in any of Debian's
> > three distributions (main, non-free, contrib)?
> I thought that policy required discussion, not just notification.
thanks for telling me ! i looked at the policy :
... (using and not using virtual packages) ...
They must not use virtual package names (except privately, amongst a
cooperating group of packages) unless they have been agreed upon
> We are still supporting their packages in the sense
> that we support their installation. Should any package
> reference packages that aren't available in any of Debian's
> three distributions (main, non-free, contrib)?
people will install them with and without our support. we can make sure,
tha
> On Fri, Nov 28, 1997 at 09:32:51AM +0100, Andreas Jellinghaus wrote:
> > > I'm not entirely unserious here. I agree with Christian's earlier
> > > post; do we really need to go out of our way to support a
> > > non-debian-maintained package?
> >
> > we don't support it. we make sure, that their
On Fri, Nov 28, 1997 at 09:32:51AM +0100, Andreas Jellinghaus wrote:
> > I'm not entirely unserious here. I agree with Christian's earlier
> > post; do we really need to go out of our way to support a
> > non-debian-maintained package?
>
> we don't support it. we make sure, that their packages wi
> At the risk of starting another flamewar, providing a KDE
> package that installs in /opt is an obvious violation of debian
> policy, which I assume is why Andreas does his own. Although
> Andreas encourages us not to get the KDE people off-side,
> sometimes it wouldn't hurt if the KDE people wou
> I'm not entirely unserious here. I agree with Christian's earlier
> post; do we really need to go out of our way to support a
> non-debian-maintained package?
we don't support it. we make sure, that their packages will not brake
our packages, and vice versa. what is wrong with this ?
andreas
p
> Andreas, would dropping the Provides from my previous solution solve your
> problems?
then we would have some sort of a "we do nothing" case. yes, it would
work, but we had to rename our packages and conflict with their version
(i can't ask other to do stupid work, then i could do it myself - th
On Thu, Nov 27, 1997 at 12:17:47AM +0100, Andreas Jellinghaus wrote:
> short term solution
> ===
>
> my solution (two virtual names) is meant to be a short term solution.
> all i want is, to inform you and to give you the possibility to offer me
^^
> a bett
On Wed, Nov 26, 1997 at 05:15:13PM -0500, Ben Pfaff wrote:
> The problem with this proposal is that there is no assurance that in
> fact the conflicting packages will have the same names; i.e., they
> might divide up the functionality in KDE into packages differently
> from the way that we do it.
On Wed, Nov 26, 1997 at 07:05:20PM +0100, Christian Schwarz wrote:
> On Wed, 26 Nov 1997, Luis Francisco Gonzalez wrote:
> > It's in the interest of our users and of not being called a "broken"
> > distribution.
>
> I don't think anyone would call our distribution "broken" if he/she
> removes som
On Thu, 27 Nov 1997, Bdale Garbee wrote:
[snip]
> Did you not read Christian's explanation of the versioning of the
> dependencies? I think that completely satisfies your concern.
>
> Frankly, I don't personally understand why Christian proposes that the KDE
> flavors of the package include "
In article <[EMAIL PROTECTED]> you wrote:
:> (For simplity and without loss of generality, I'm just describing the
:> solution for kdebase and kdegraphics. Furthermore, the "Depends:" lines
:> have been simplified.)
:>
:> The Debian packages:
:> Package: kdelibs0g
:>
:> Package: kdebase
:> De
On Wed 26 Nov 1997, Bdale Garbee wrote:
> In article <[EMAIL PROTECTED]> you wrote:
>
> : their packages are available, ours not...
>
> I think there are two things that I must have missed in the discussion on this
> topic:
>
> - why are there two sets of KDE packages? One should be suffi
> (For simplity and without loss of generality, I'm just describing the
> solution for kdebase and kdegraphics. Furthermore, the "Depends:" lines
> have been simplified.)
>
> The Debian packages:
> Package: kdelibs0g
>
> Package: kdebase
> Depends: kdelibs0g, ...
>
> Package: kdegraphics
>
> Won't our turning off --force-overwrite in 2.0 be a more realistic
> solution of this problem? Aren't most package conflicts really
> related to their usage of competing file structures? Or am I totally
> off-base here?
kde's version of kdelib is not compatible with my kdelib :
we have differe
Andreas,
please tell us which problems you see with the following solution.
(For simplity and without loss of generality, I'm just describing the
solution for kdebase and kdegraphics. Furthermore, the "Depends:" lines
have been simplified.)
The Debian packages:
Package: kdelibs0g
Package:
On Wed, Nov 26, 1997 at 10:07:08PM -0700, Bdale Garbee wrote:
> In article <[EMAIL PROTECTED]> you wrote:
>
> : their packages are available, ours not...
>
> I think there are two things that I must have missed in the discussion on this
> topic:
>
> - why are there two sets of KDE packages
In article <[EMAIL PROTECTED]> you wrote:
: their packages are available, ours not...
I think there are two things that I must have missed in the discussion on this
topic:
- why are there two sets of KDE packages? One should be sufficient.
- why can't "your" KDE packages be mad
short term solution
===
my solution (two virtual names) is meant to be a short term solution.
all i want is, to inform you and to give you the possibility to offer me
a better short term solution.
long term solution
==
anything that needs a policy discussion/findi
> I don't think anyone would call our distribution "broken" if he/she
> removes some of our packages, replaces them with someone else ones, and
> fails.
hey, it can also work the other direction.
their packages are available, ours not...
andreas
Enrique Zanardi <[EMAIL PROTECTED]> writes:
> > However, let me make another suggestion: We add a new control field to our
> > packages, namely `Distributor'. All Debian packages will get
> >
> > `Distributor: SPI'
> >
> > and everyone outside the project should use something else, e.g.
> >
On Wed, 26 Nov 1997, Christian Schwarz wrote:
> However, let me make another suggestion: We add a new control field to our
> packages, namely `Distributor'. All Debian packages will get
>
> `Distributor: SPI'
>
> and everyone outside the project should use something else, e.g.
>
> `Di
On Wed, 26 Nov 1997, Luis Francisco Gonzalez wrote:
[snip]
> I think Andreas is right here. It'll be debian users that will suffer. I
> don't feel I know enough of the packages and kde to be sure which is the best
> technical solution but I do think we should work something out. And this
> regar
On Tue, 25 Nov 1997, Andreas Jellinghaus wrote:
> > No. We'll definitely not clutter our virtual package list just to support
> > some outside group distributing replacment packages for ours.
> >
> > I suggest that you leave the kde* packages as they are now (have been
> > before that change) so
> As our packaging format becomes more popular (and we really want it,
> don't we?) there will be more upstream authors that package their
> programs as "deb" but don't follow our policies (non-FSSTND-compliant
> packages, for example).
>
> What are we going to do to avoid conflicts between their
On Wed, 26 Nov 1997, Luis Francisco Gonzalez wrote:
> I think Andreas is right here. It'll be debian users that will suffer. I
> don't feel I know enough of the packages and kde to be sure which is the best
> technical solution but I do think we should work something out. And this
> regardless o
Andreas Jellinghaus wrote
> > No. We'll definitely not clutter our virtual package list just to support
> > some outside group distributing replacment packages for ours.
> >
> > I suggest that you leave the kde* packages as they are now (have been
> > before that change) so that they don't provide
> No. We'll definitely not clutter our virtual package list just to support
> some outside group distributing replacment packages for ours.
>
> I suggest that you leave the kde* packages as they are now (have been
> before that change) so that they don't provide anything and that they
> suggest ea
On Sun, 23 Nov 1997, Andreas Jellinghaus wrote:
> i generate a .deb verion of kde, and kde does the same.
> to seperate them, i use two packages :
> a) debian-kde.deb-package
> b) kde-kde.deb-package
>
> all my packages provide: a), suggests: a) and conflicts: b)
>
> please register these packages
On 24-Nov-1997 03:38:49, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
> > Surely it is sufficient for your packages to Conflicts: theirs
> > and theirs to Conflicts: yours.
>
> i need the provides: so i have something to conflicts: to.
You can conflict against real packages -- there's no need f
> Surely it is sufficient for your packages to Conflicts: theirs
> and theirs to Conflicts: yours.
i need the provides: so i have something to conflicts: to.
> Also, should Conflicts: etc refer to packages outside the distribution,
> eg the KDE-done kde packages? Unless we are planning to distrib
On Sun, Nov 23, 1997 at 06:37:18PM +0100, Andreas Jellinghaus wrote:
> i generate a .deb verion of kde, and kde does the same.
> to seperate them, i use two packages :
> a) debian-kde.deb-package
> b) kde-kde.deb-package
>
> all my packages provide: a), suggests: a) and conflicts: b)
>
> please r
i generate a .deb verion of kde, and kde does the same.
to seperate them, i use two packages :
a) debian-kde.deb-package
b) kde-kde.deb-package
all my packages provide: a), suggests: a) and conflicts: b)
please register these packages in the virtual package list.
andreas
45 matches
Mail list logo
