FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 02-16-2011, 11:42 PM
Dan McGee
 
Default Version specs in replaces

So the first command makes sense, and at least right now we parse
conflicts like we do depends- we allow version specifiers. However, I
found the oddity with REPLACES when doing some archweb work tonight.
Should we be allowing this? Should it be restricted to '=' only like
provides? I'm not sure, so please chime in.

On this note, it would probably be good to make sure we have all the
proper definitions nailed down in the manpage, as well as sanity
checks in makepkg:

depends: name[(=|<|<=|>=|>)version]
makedepends: name[(=|<|<=|>=|>)version] (same as depends)
checkdepends: name[(=|<|<=|>=|>)version] (same as depends)
optdepends: name[(=|<|<=|>=|>)version][: description] (this one is a bit tricky)
conflicts: name[(=|<|<=|>=|>)version] (same as depends)
provides: name[=version]
replaces: name (???)

-Dan

dmcgee@galway ~/projects/archweb (master)
$ zcat /tmp/updaterepos/i686/*.db.tar.gz | grep -A 1 -a CONFLICTS |
grep -a '[=><]' | sort | uniq
abiword-plugins<2.8.6-4
cloog-ppl<0.15.10-2
dbus<1.2.3-2
gnome-panel<2.31.92
gstreamer0.10-bad<=0.10.17
gtkmm<2.13.0
libx11<1.1.99.2
mesa<7.9
mkinitcpio<0.5.99
mlt++<=0.3.8
nexuiz<2.5.1-3
nvidia-utils<190.42-2
poppler<0.10.5
poppler-qt3<0.16.2
python<3
qt4-doc=4.7.1
tremulous<=1.1.0-5
wesnoth<1.8.5
xf86-video-ati<6.9.0-6
xf86-video-mach64<6.8.2
xf86-video-mga<1.4.11
xf86-video-r128<6.8.1
xf86-video-savage<2.3.1
xf86-video-sis<0.10.2
xf86-video-tdfx<1.4.3
xorg-server<1.9.0

dmcgee@galway ~/projects/archweb (master)
$ zcat /tmp/updaterepos/i686/*.db.tar.gz | grep -A 1 -a REPLACES |
grep -a '[=><]' | sort | uniq
haskell-array<0.3.0.1
 
Old 02-17-2011, 10:00 AM
Allan McRae
 
Default Version specs in replaces

On 17/02/11 10:42, Dan McGee wrote:

So the first command makes sense, and at least right now we parse
conflicts like we do depends- we allow version specifiers. However, I
found the oddity with REPLACES when doing some archweb work tonight.
Should we be allowing this? Should it be restricted to '=' only like
provides? I'm not sure, so please chime in.


I am struggling to think of any case where it would be appropriate to
have a version in a replaces entry.


Allan
 
Old 02-17-2011, 10:26 AM
Daenyth Blank
 
Default Version specs in replaces

On Thu, Feb 17, 2011 at 06:00, Allan McRae <allan@archlinux.org> wrote:
> On 17/02/11 10:42, Dan McGee wrote:
>>
>> So the first command makes sense, and at least right now we parse
>> conflicts like we do depends- we allow version specifiers. However, I
>> found the oddity with REPLACES when doing some archweb work tonight.
>> Should we be allowing this? Should it be restricted to '=' only like
>> provides? I'm not sure, so please chime in.
>
> I am struggling to think of any case where it would be appropriate to have a
> version in a replaces entry.
>
> Allan
>
>
I ran into this the other day. An example would be python-yaml in
community. Currently it's for python 2. I'm going to switch it so that
there's a python2-yaml package and python-yaml would be python3. It
would make sense for python2-yaml to
REPLACES=("python-yaml<$py3k_version")
 
Old 02-18-2011, 07:08 PM
Dan McGee
 
Default Version specs in replaces

On Thursday, February 17, 2011, Daenyth Blank <daenyth+arch@gmail.com> wrote:
> On Thu, Feb 17, 2011 at 06:00, Allan McRae <allan@archlinux.org> wrote:
>> On 17/02/11 10:42, Dan McGee wrote:
>>>
>>> So the first command makes sense, and at least right now we parse
>>> conflicts like we do depends- we allow version specifiers. However, I
>>> found the oddity with REPLACES when doing some archweb work tonight.
>>> Should we be allowing this? Should it be restricted to '=' only like
>>> provides? I'm not sure, so please chime in.
>>
>> I am struggling to think of any case where it would be appropriate to have a
>> version in a replaces entry.
>>
>> Allan
>>
>>
> I ran into this the other day. An example would be python-yaml in
> community. Currently it's for python 2. I'm going to switch it so that
> there's a python2-yaml package and python-yaml would be python3. It
> would make sense for python2-yaml to
> REPLACES=("python-yaml<$py3k_version")

Any other input from anyone before Allan and I lock the definition
down, and then make the code work appropriately?

-Dan
 
Old 02-18-2011, 11:44 PM
Xavier Chantry
 
Default Version specs in replaces

On Fri, Feb 18, 2011 at 9:08 PM, Dan McGee <dpmcgee@gmail.com> wrote:
> On Thursday, February 17, 2011, Daenyth Blank <daenyth+arch@gmail.com> wrote:
>> On Thu, Feb 17, 2011 at 06:00, Allan McRae <allan@archlinux.org> wrote:
>>> On 17/02/11 10:42, Dan McGee wrote:
>>>>
>>>> So the first command makes sense, and at least right now we parse
>>>> conflicts like we do depends- we allow version specifiers. However, I
>>>> found the oddity with REPLACES when doing some archweb work tonight.
>>>> Should we be allowing this? Should it be restricted to '=' only like
>>>> provides? I'm not sure, so please chime in.
>>>
>>> I am struggling to think of any case where it would be appropriate to have a
>>> version in a replaces entry.
>>>
>>> Allan
>>>
>>>
>> I ran into this the other day. An example would be python-yaml in
>> community. Currently it's for python 2. I'm going to switch it so that
>> there's a python2-yaml package and python-yaml would be python3. It
>> would make sense for python2-yaml to
>> REPLACES=("python-yaml<$py3k_version")
>
> Any other input from anyone before Allan and I lock the definition
> down, and then make the code work appropriately?
>

Versioned replace sounds good to me, and Daenyth provided an example.
 

Thread Tools




All times are GMT. The time now is 12:00 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org