On Thursday 25 February 2010 04:34:06 Allan McRae wrote:
I have had a quick look at these today and there are still a couple of
things I would like to address. but they are getting much closer to
what I think they need to be.
I have put them on a sodeps branch of my pacman repo so they do
On 13.04.2010 19:10, Frank Thieme wrote:
On Thursday 25 February 2010 04:34:06 Allan McRae wrote:
I have had a quick look at these today and there are still a couple of
things I would like to address. but they are getting much closer to
what I think they need to be.
I have put them on a
On 14/02/10 21:27, Florian Pritz wrote:
On 02/10/2010 07:02 PM, Florian Pritz wrote:
On 02/10/2010 07:08 AM, Allan McRae wrote:
provides=(foobar libfoo.so)
would result in
provides = foobar
provides = libfoo.so=6-x86_64 (does that order look right...?)
in the .PKGINFO file.
I am fairly
On 02/10/2010 07:02 PM, Florian Pritz wrote:
On 02/10/2010 07:08 AM, Allan McRae wrote:
provides=(foobar libfoo.so)
would result in
provides = foobar
provides = libfoo.so=6-x86_64 (does that order look right...?)
in the .PKGINFO file.
I am fairly sure that pacman can handle two
On 02/10/2010 07:08 AM, Allan McRae wrote:
provides=(foobar libfoo.so)
would result in
provides = foobar
provides = libfoo.so=6-x86_64 (does that order look right...?)
in the .PKGINFO file.
I am fairly sure that pacman can handle two packages providing different
versions of
On 05/02/10 01:38, Thomas Bächler wrote:
Am 04.02.2010 15:32, schrieb Allan McRae:
3) I would like the sodeps to be listed like (e.g) libreadline.so.
This makes the dependency named closer to what is actually is. Makepkg
could recognize the .so at the end and use readelf on the binaries and
On 06/02/10 10:00, Florian Pritz wrote:
+#-- soprovides:add .so files to provides array
#
-OPTIONS=(strip docs libtool emptydirs zipman purge)
+OPTIONS=(strip docs libtool emptydirs zipman purge soprovides)
Just a small comment on this. Do we really need the new option here? I
think that
* Florian Pritz bluew...@server-speed.net wrote:
The current patch adds sodep-$arch-$soFileName for every .so file
that's owned by a package in the depends array. Files from optdepends
are silently ignored and if no dependency owns the file there will be a
warning.
I've just rebased the old
Am 06.02.2010 01:00, schrieb Florian Pritz:
For the arch part a better way to find the arch of the lib would be
nice. Neither readelf nor objdump seem to fit. Readelf only shows 32/64
and objdump shows i686 libs as i368. If anyone has an idea please share.
Technically, i686 is i386, just a
Am 03.02.2010 21:17, schrieb Pierre Schmitz:
Am Mittwoch, 3. Februar 2010 10:27:43 schrieb Thomas Bächler:
I get the feeling that you are desperately looking for reason to not
implement a feature that is obviously a necesity.
I like the idea of adding sodeps and soprovides. Ideally they
On 04/02/10 22:54, Thomas Bächler wrote:
However, it's worthless to discuss implementation and concepts if the
idea is entirely rejected by our main makepkg developer.
It is not entirely rejected. I just have very limited time at the
moment so end up just pointing out what I do not like
Am 04.02.2010 15:32, schrieb Allan McRae:
It is not entirely rejected. I just have very limited time at the
moment so end up just pointing out what I do not like about ideas. I
actually do like some of the idea, but there are parts I obviously
dislike. In future I'll put some effort into
1) I'd prefer just using a single depends array rather than an
additional sodepends array. A version of pacman's -d ignoring
dependency versioning would not require a separate array and would be
far more useful than one that ignored sodepends. I think that should be
implemented in
Am 03.02.2010 01:39, schrieb Allan McRae:
I will have a decent look into that patch later, but I still think it is
a bit of a false sense of security.
e.g readline-6.0 and readline-6.1 both provide libreadline.so.6.
However, building bash against readline-6.1 and running against
Finally, this would prevent proper upgrades to partially complete
rebuilds. That is fine for some users who would like such things, but
the people doing and testing a rebuild would have issues. I upgraded
the libpng/libjpeg rebuild packages while there were still several
packages needing to be
Am Mittwoch, 3. Februar 2010 10:27:43 schrieb Thomas Bächler:
I get the feeling that you are desperately looking for reason to not
implement a feature that is obviously a necesity.
I like the idea of adding sodeps and soprovides. Ideally they should be even
added to the db files so tools could
On 01/22/2010 09:19 PM, Florian Pritz wrote:
Hi,
Regarding the current mass rebuilds because of libpng I'd like to
suggest implementing so dependencies again.
Bump.
I'd really like to get some comments regarding this patch.
--
Florian Pritz -- {flo,bluewi...@server-speed.net
On 02/02/2010 09:13 PM, Nagy Gabor wrote:
This is not the competent ML to decide if ArchLinux's repos should use
these flags, personally I have some concerns about db.tar.gz size. (That
needs testing, which requires patched makepkg, too.)
I've repacked core and the results are quite good:
On 02/02/2010 09:13 PM, Nagy Gabor wrote:
This is not the competent ML to decide if ArchLinux's repos should use
these flags, personally I have some concerns about db.tar.gz size. (That
needs testing, which requires patched makepkg, too.)
I've repacked core and the results are quite
On 02/02/2010 09:13 PM, Nagy Gabor wrote:
This is not the competent ML to decide if ArchLinux's repos should use
these flags, personally I have some concerns about db.tar.gz size. (That
needs testing, which requires patched makepkg, too.)
I've repacked core and the results are
20 matches
Mail list logo
