On Sunday 18 August 2002 20:36, Chris Cheney wrote:
> On Sun, Aug 18, 2002 at 06:09:18PM +0200, Luca Barbieri wrote:
>> For example, how about calc.cx KDE 3.0 packages that are obviously
>> necessary for any KDE user? I don't see any mention of GCC 3.2 on their
>> text file so I assume that they a
I've managed to patch both dpkg and glibc.
However the resulting system does not work because some things like KDE
use absolute paths so they would too need to be fixed.
Furthermore, we have the problem of C++ library packages including
non-C++ files. This can only be handled by heavily modifying
Le sam 17/08/2002 à 18:50, Luca Barbieri a écrit :
> I forgot an important thing: all new non-C++ packages should be tagged
> as non-C++ in some way so that dpkg doesn't need to scan them.
>
> This should of course be done by having the build tools scan the package
> build directory and set either
On Sun, Aug 18, 2002 at 08:36:21PM +0200, Luca Barbieri wrote:
> On Sun, 2002-08-18 at 20:08, Erich Schubert wrote:
> > > > hacking the dynamic linker certainly is better than that...
> > > This only allows to avoid creating wrappers but doesn't avoid the
> > > problem that two libraries can't have
> > > > Aren't the G++ 3.2 packages going to be moved into sarge? Even if you do
> > > > so when the transition is complete, there will still be non-Debian G++
> > > > v2 packages installed on users' machines.
> > >
> > > No, they are not, as long as there are dependency problems, and as long
> >
> > No. The maintainer must, by uploading a new version of the old library,
> > and using proper Conflicts. That way other packages can depend on the
> > moved versions properly.
> And it is not possible to install both a v2 ABI and a v3 ABI version of
> the library.
Sure it is. One of the package
On Sun, 2002-08-18 at 20:08, Erich Schubert wrote:
> > > hacking the dynamic linker certainly is better than that...
> > This only allows to avoid creating wrappers but doesn't avoid the
> > problem that two libraries can't have the same filename.
> > Something (dpkg) must move one of them.
>
> No
On Sun, Aug 18, 2002 at 06:09:18PM +0200, Luca Barbieri wrote:
> > Of course there is. You upload new versions of the gcc 2.95 packages,
> > and you make the new gcc 3.2 packages conflict with the old ones.
> > Nothing is broken in that case.
> False.
> Users will no longer get updated version of
>> Luca Barbieri <[EMAIL PROTECTED]> writes:
> I have already managed to write a program to detect the ABI
Can you put that somewhere for download?
--
Marcelo | She'd even given herself a middle initial - X - which
[EMAIL PROTECTED] | stood for "someone who has a cool and exciting
> > hacking the dynamic linker certainly is better than that...
> This only allows to avoid creating wrappers but doesn't avoid the
> problem that two libraries can't have the same filename.
> Something (dpkg) must move one of them.
No. The maintainer must, by uploading a new version of the old li
> I certainly prefer NOT doing any ugly stuff with dpkg.
> "apt-get dist-upgrade" will uninstall packages that havn't been updated
> to the new c++ yet, which certainly is worth a bug report on these
> packages...
Oops, I meant upgrade not dist-upgrade. dist-upgrade is bad :)
> That is exactly the
On Sun, Aug 18, 2002 at 06:09:18PM +0200, Luca Barbieri wrote:
> > > Of course it would be better to avoid having to do things like this but
> > > unfortunately there is simply no other solution that doesn't break
> > > existing G++ v2 packages.
> > Of course there is. You upload new versions of
I certainly prefer NOT doing any ugly stuff with dpkg.
"apt-get dist-upgrade" will uninstall packages that havn't been updated
to the new c++ yet, which certainly is worth a bug report on these
packages...
That is exactly the PRO of a good dependency management...
Instead of hacking some ugly stuff
On Sun, 2002-08-18 at 17:47, Steve Langasek wrote:
> On Sun, Aug 18, 2002 at 05:36:04PM +0200, Luca Barbieri wrote:
> > > No because it is overcomplicated
> > This isn't a problem for you, I'm doing the work (I have already managed
> > to write a program to detect the ABI, a wrapper generator and p
On Sun, Aug 18, 2002 at 05:36:04PM +0200, Luca Barbieri wrote:
> > No because it is overcomplicated
> This isn't a problem for you, I'm doing the work (I have already managed
> to write a program to detect the ABI, a wrapper generator and patched dpkg
> to move libraries; I still have to do shlibs
On Sun, Aug 18, 2002 at 05:36:04PM +0200, Luca Barbieri wrote:
> > No because it is overcomplicated
> This isn't a problem for you, I'm doing the work (I have already managed
> to write a program to detect the ABI, a wrapper generator and patched
> dpkg to move libraries; I still have to do shlibs
On Sun, Aug 18, 2002 at 05:36:04PM +0200, Luca Barbieri wrote:
> > No because it is overcomplicated
> This isn't a problem for you, I'm doing the work
Yes it is a problem for us; we as package maintainers have to deal with
what happens when it goes wrong. dpkg is already complicated and having
it
> No because it is overcomplicated
This isn't a problem for you, I'm doing the work (I have already managed
to write a program to detect the ABI, a wrapper generator and patched
dpkg to move libraries; I still have to do shlibs support and hook the
wrapper generator to dpkg).
If it isn't accepted,
On Sat, Aug 17, 2002 at 06:28:27PM +0200, Luca Barbieri wrote:
> > HAHAHAHAHA. No.
> >
> > .__.
> > _|doogie|_ <-- dpkg hat
> >
> No because of technical reasons, or because it's too much work?
No because it is overcomplicated and dpkg has no business making this kind
of on-the-fly adjust
> Because you have no clue what you are talking about.
The problem is that people who have a clue are proposing solutions that
would break existing packages and would cause the user to recompile
everything he has compiled on his own.
Furthermore, they don't explain what is wrong with the approach
On 17 Aug 2002, Luca Barbieri wrote:
> > HAHAHAHAHA. No.
> >
> > .__.
> > _|doogie|_ <-- dpkg hat
> >
> No because of technical reasons, or because it's too much work?
Because you have no clue what you are talking about.
Luca Barbieri wrote:
HAHAHAHAHA. No.
.__.
_|doogie|_ <-- dpkg hat
No because of technical reasons, or because it's too much work?
IMHO: No because it is unclean/ugly/fragile/hacky/total mess/etc.
IMHO since changing library filenames breaks compatibility with other
distributions, this is the o
I forgot an important thing: all new non-C++ packages should be tagged
as non-C++ in some way so that dpkg doesn't need to scan them.
This should of course be done by having the build tools scan the package
build directory and set either a new field ('Uses-C++-ABI: No') or by
dependency on the new
> HAHAHAHAHA. No.
>
> .__.
> _|doogie|_ <-- dpkg hat
>
No because of technical reasons, or because it's too much work?
IMHO since changing library filenames breaks compatibility with other
distributions, this is the only way to allow installation of old
packages (that, still IMHO, must abs
On 17 Aug 2002, Luca Barbieri wrote:
> Here is a plan on how to do so. It requires to modify dpkg but allows
> complete compatibility and no breakage of binaries (building with
> G++-2.95 would no longer work unless wrappers are written).
>
> 1. Create a new version of dpkg that does the following
Here is a plan on how to do so. It requires to modify dpkg but allows
complete compatibility and no breakage of binaries (building with
G++-2.95 would no longer work unless wrappers are written).
1. Create a new version of dpkg that does the following;
In the postinst script it checks whether /us
26 matches
Mail list logo
