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 Development

 
 
LinkBack Thread Tools
 
Old 01-17-2008, 07:08 PM
Eric Belanger
 
Default Versioned Provisions

On Thu, 17 Jan 2008, Aaron Griffin wrote:


This is a little "heads up" email to all the package maintainers out there.

Pacman 3.1 has support for versioned provisions. But what this also
means is that there's going to be some breakages in packages.

Let me explain by way of example:

package foo depends=(bar>=1.2)
package omg provides=(bar)

In the past, you could install both foo and omg at the same time and
everything would be satisfied. Not now. Now, the provision of "omg"
will fail, because it's not providing the right version.

What does this mean? Well, a few things. First and foremost, versioned
provisions are a little broken in 3.1.0, but 3.1.1 will fix all this
py allowing you to say:
provides=(bar=1.2)


In this example, would
provides=(bar>=1.2)
also work?



Did I get this right? Dan, Xavier?




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
 
Old 01-17-2008, 07:36 PM
"Aaron Griffin"
 
Default Versioned Provisions

On Jan 17, 2008 2:08 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
> In this example, would
> provides=(bar>=1.2)
> also work?

No versioned provisions only support "=" for now, and the rationale,
in my head, is that versioned provisions are a little goofy to begin
with, so it makes sense to need to keep a closer eye on them.
 
Old 01-17-2008, 08:49 PM
Xavier
 
Default Versioned Provisions

Aaron Griffin wrote:

This is a little "heads up" email to all the package maintainers out there.

Pacman 3.1 has support for versioned provisions. But what this also
means is that there's going to be some breakages in packages.

Let me explain by way of example:

package foo depends=(bar>=1.2)
package omg provides=(bar)

In the past, you could install both foo and omg at the same time and
everything would be satisfied. Not now. Now, the provision of "omg"
will fail, because it's not providing the right version.

What does this mean? Well, a few things. First and foremost, versioned
provisions are a little broken in 3.1.0, but 3.1.1 will fix all this
py allowing you to say:
provides=(bar=1.2)

Did I get this right? Dan, Xavier?



Yes, I only want to clarify that packagers need to wait for 3.1.1 to be
released before starting to update their packages.


And this feature is useful because in the above case, omg package could
be at version 0.1.

pacman 3.0 deduced from this that omg package provided bar-0.1
But there was no way to specify that omg actually provided bar-1.2, and
thus satisfied the bar>=1.2 dependency of foo package.


There is one point that wasn't appreciated by several people though.
When no provision version is specified, pacman no longer defaults to the
package version. Why?
Consider for example in the above case that the package omg is at
version 2.0, but doesn't provide 1.2 version of bar, only 1.0.
With the old behavior, pacman would still accept to install omg package
as a dependency of foo, which would result in a broken system.


Finally, there are quite a few cases where the package version and the
provision version are not related. You can have a look at all provides
lines in the /var/abs tree :
find /var/abs -name PKGBUILD | xargs egrep '^provides|^pkgname|^pkgver'
|grep provides -B2


First, there are virtual provisions, like sh, cron, smtp-server.
But there are other good candidates, here are a few ones:
nvidia-utils and fglrx-utils provide libgl
avahi provides howl and mdnsresponder
python provides python-ctypes
gamin provides fam
etc...

And then consider all the devel packages (cvs, svn, etc).
 
Old 01-17-2008, 08:49 PM
Xavier
 
Default Versioned Provisions

Aaron Griffin wrote:

This is a little "heads up" email to all the package maintainers out there.

Pacman 3.1 has support for versioned provisions. But what this also
means is that there's going to be some breakages in packages.

Let me explain by way of example:

package foo depends=(bar>=1.2)
package omg provides=(bar)

In the past, you could install both foo and omg at the same time and
everything would be satisfied. Not now. Now, the provision of "omg"
will fail, because it's not providing the right version.

What does this mean? Well, a few things. First and foremost, versioned
provisions are a little broken in 3.1.0, but 3.1.1 will fix all this
py allowing you to say:
provides=(bar=1.2)

Did I get this right? Dan, Xavier?



Yes, I only want to clarify that packagers need to wait for 3.1.1 to be
released before starting to update their packages.


And this feature is useful because in the above case, omg package could
be at version 0.1.

pacman 3.0 deduced from this that omg package provided bar-0.1
But there was no way to specify that omg actually provided bar-1.2, and
thus satisfied the bar>=1.2 dependency of foo package.


There is one point that wasn't appreciated by several people though.
When no provision version is specified, pacman no longer defaults to the
package version. Why?
Consider for example in the above case that the package omg is at
version 2.0, but doesn't provide 1.2 version of bar, only 1.0.
With the old behavior, pacman would still accept to install omg package
as a dependency of foo, which would result in a broken system.


Finally, there are quite a few cases where the package version and the
provision version are not related. You can have a look at all provides
lines in the /var/abs tree :
find /var/abs -name PKGBUILD | xargs egrep '^provides|^pkgname|^pkgver'
|grep provides -B2


First, there are virtual provisions, like sh, cron, smtp-server.
But there are other good candidates, here are a few ones:
nvidia-utils and fglrx-utils provide libgl
avahi provides howl and mdnsresponder
python provides python-ctypes
gamin provides fam
etc...

And then consider all the devel packages (cvs, svn, etc).
 
Old 01-17-2008, 10:50 PM
"Dan McGee"
 
Default Versioned Provisions

On Jan 17, 2008 3:49 PM, Xavier <shiningxc@gmail.com> wrote:
>
> Aaron Griffin wrote:
> > This is a little "heads up" email to all the package maintainers out there.
> >
> > Pacman 3.1 has support for versioned provisions. But what this also
> > means is that there's going to be some breakages in packages.

In addition to all else that was said, I will offer the following.

In 3.1.0, you may have heard or read that the provisions format was like this:
provides=('cairo 1.1')

3.1.1 will change it to this:
provides=('cairo=1.1')

The reason for the switch came down to two things- an error in
repo-add dealing with the space, and the issue that packagers would
forget the quotes on their provision (even Aaron did it above!). If we
use the = instead of a ' ' (space), we can avoid these two issues.

What this does *NOT* mean is that versioned provisions will ever be
supported. This is the reason we did not go with the = sign
originally- it might lead packagers to believe they were supported.
Versioned provisions really don't make sense- if someone can provide a
use case, I can probably debunk it.

-Dan
 
Old 01-17-2008, 10:50 PM
"Dan McGee"
 
Default Versioned Provisions

On Jan 17, 2008 3:49 PM, Xavier <shiningxc@gmail.com> wrote:
>
> Aaron Griffin wrote:
> > This is a little "heads up" email to all the package maintainers out there.
> >
> > Pacman 3.1 has support for versioned provisions. But what this also
> > means is that there's going to be some breakages in packages.

In addition to all else that was said, I will offer the following.

In 3.1.0, you may have heard or read that the provisions format was like this:
provides=('cairo 1.1')

3.1.1 will change it to this:
provides=('cairo=1.1')

The reason for the switch came down to two things- an error in
repo-add dealing with the space, and the issue that packagers would
forget the quotes on their provision (even Aaron did it above!). If we
use the = instead of a ' ' (space), we can avoid these two issues.

What this does *NOT* mean is that versioned provisions will ever be
supported. This is the reason we did not go with the = sign
originally- it might lead packagers to believe they were supported.
Versioned provisions really don't make sense- if someone can provide a
use case, I can probably debunk it.

-Dan
 
Old 01-17-2008, 11:19 PM
Xavier
 
Default Versioned Provisions

Dan McGee wrote:


What this does *NOT* mean is that versioned provisions will ever be
supported. This is the reason we did not go with the = sign
originally- it might lead packagers to believe they were supported.
Versioned provisions really don't make sense- if someone can provide a
use case, I can probably debunk it.



Just to clarify, what Dan meant here is that the only supported operator
is = (no >=, <=, >, <).
 
Old 01-17-2008, 11:19 PM
Xavier
 
Default Versioned Provisions

Dan McGee wrote:


What this does *NOT* mean is that versioned provisions will ever be
supported. This is the reason we did not go with the = sign
originally- it might lead packagers to believe they were supported.
Versioned provisions really don't make sense- if someone can provide a
use case, I can probably debunk it.



Just to clarify, what Dan meant here is that the only supported operator
is = (no >=, <=, >, <).
 
Old 01-17-2008, 11:19 PM
"Aaron Griffin"
 
Default Versioned Provisions

On Jan 17, 2008 5:50 PM, Dan McGee <dpmcgee@gmail.com> wrote:
> forget the quotes on their provision (even Aaron did it above!). If we

Hah, but I know bash parsing rules!

> What this does *NOT* mean is that versioned provisions will ever be
> supported. This is the reason we did not go with the = sign
> originally- it might lead packagers to believe they were supported.
> Versioned provisions really don't make sense- if someone can provide a
> use case, I can probably debunk it.

Um, I think you misspoke a little here. I assume you meant to add
something other than "versioned provisions will ever be supported".
I'd guess, based on context, you meant to indicate the ">=" and "<="
stuff, right?
 
Old 01-17-2008, 11:19 PM
"Aaron Griffin"
 
Default Versioned Provisions

On Jan 17, 2008 5:50 PM, Dan McGee <dpmcgee@gmail.com> wrote:
> forget the quotes on their provision (even Aaron did it above!). If we

Hah, but I know bash parsing rules!

> What this does *NOT* mean is that versioned provisions will ever be
> supported. This is the reason we did not go with the = sign
> originally- it might lead packagers to believe they were supported.
> Versioned provisions really don't make sense- if someone can provide a
> use case, I can probably debunk it.

Um, I think you misspoke a little here. I assume you meant to add
something other than "versioned provisions will ever be supported".
I'd guess, based on context, you meant to indicate the ">=" and "<="
stuff, right?
 

Thread Tools




All times are GMT. The time now is 08:45 AM.

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