[pacman-dev] Problems with frugalware splitname changes

older
[pacman-dev] [PATCH] Java bindings

Aaron Griffin

8 Oct 2006 8 Oct '06

7:27 a.m.

The changes to the alpm splitname function are fine and all, except they do not accomodate archlinux packages, which do not append the architecture to the end of the package name (instead we put them in directories based on the architecture). Could you please make these changes so that they can accomodate for either arch of frugalware? Currently, it directs pacman to install a foo-1.0-1-.pkg.tar.gz package. (note the trailing dash). I have a few more things to delve through, but I won't be back until late tonight, so I figured I could poke you guys to make the change (if you have time). Thanks, Aaron Griffin

Show replies by date

VMiklos

8 Oct 8 Oct

8:48 a.m.

On Sat, Oct 07, 2006 at 06:27:37PM -0500, Aaron Griffin wrote:

...

late tonight, so I figured I could poke you guys to make the change (if you have time).

what about checking for /etc/arch-release or /etc/frugalware-release (feel free to decide for what should we check) then we could #ifdef the code anyway, here are the original changes those could be #ifdef'ed: http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=commitdiff;h=20...; udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Aaron Griffin

12:25 p.m.

On 10/7/06, VMiklos wrote:

...

On Sat, Oct 07, 2006 at 06:27:37PM -0500, Aaron Griffin wrote: anyway, here are the original changes those could be #ifdef'ed: http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=commitdiff;h=20...;

An ifdef would certainly work, but there's a point where to code is going to diverge too greatly... I mean how many #ifdef FRUGALWARE changes will we end up with. In some of these cases, we should be able to check, on-the-fly, if it has an arch name or not. I don't know about _all_ of them, but it should be straightforward to actually check.... I need to think about it though. Arch packages do have an architecture value, but it's not used in the package name, so it would be a tad difficult to reconstruct... I'm assuming there's no way to convince you guys to make extra dirs for your different architectures instead of appending it to the pakcage name, is there? 8)

Jason Chu

1:58 p.m.

On Sat, 7 Oct 2006 23:25:15 -0500 "Aaron Griffin" wrote:

...

On 10/7/06, VMiklos wrote:

...
On Sat, Oct 07, 2006 at 06:27:37PM -0500, Aaron Griffin wrote: anyway, here are the original changes those could be #ifdef'ed: http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=commitdiff;h=20...;

An ifdef would certainly work, but there's a point where to code is going to diverge too greatly... I mean how many #ifdef FRUGALWARE changes will we end up with.

In some of these cases, we should be able to check, on-the-fly, if it has an arch name or not. I don't know about _all_ of them, but it should be straightforward to actually check.... I need to think about it though. Arch packages do have an architecture value, but it's not used in the package name, so it would be a tad difficult to reconstruct...

I'm assuming there's no way to convince you guys to make extra dirs for your different architectures instead of appending it to the pakcage name, is there? 8)

Instead of checking for /etc/arch-release or /etc/frugalware-release, why not make it an autoconf option? --with-arch-in-filename or something... Trying to guess if the architecture is included in the filename isn't possible reliably. foo-bar-2.4-1 is ambiguous and a pretty common case. Jason

Aaron Griffin

7:21 p.m.

On 10/8/06, Jason Chu wrote:

...

Instead of checking for /etc/arch-release or /etc/frugalware-release, why not make it an autoconf option? --with-arch-in-filename or something...

That would work too, but I would feel more comfortable with the on-the-fly parsing. I mean, if we decide we want to have the arch name in the file name at a later date, this would allow us to make changes a few packages at a time without breaking things in the least.

...

Trying to guess if the architecture is included in the filename isn't possible reliably. foo-bar-2.4-1 is ambiguous and a pretty common case.

The arch is added at the end in this patch, after the pkgrel, so there is no ambiguity foo-bar-2.4-1-i686 foo-bar-2.4-1-x86_64 etc etc

VMiklos

7:58 p.m.

On Sun, Oct 08, 2006 at 06:21:27AM -0500, Aaron Griffin wrote:

...

The arch is added at the end in this patch, after the pkgrel, so there is no ambiguity foo-bar-2.4-1-i686 foo-bar-2.4-1-x86_64 etc etc

okay, but then we should hardcore the list of possible arches. or how could we determine of the last item is an arch or a pkgrel? checking if the last item is an integer or not could work, but for security support we use non-integer pkgrels to avoid the following scenario: foo-1.0-1 has a security bug and there is a vendor patch to fix the issue. so we upload foo-1.0-2 to -current. foo-1.0-2 is built against libbar.so.1. then we upload foo-1.0-2siwenna1 to -stable, compiled against libbar.so.0 (in a -stable chroot). this way when a user upgrades to -current his "foo" pkg will be upgraded and will be linked to the right version of libbar hardcoding the archlist is ugly, but if we really want to do this runtime, then i think we need to do so or have i missed something? udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Christian Hamar

8:11 p.m.

2006. 10. 8, vasárnap keltezéssel 06.21-kor Aaron Griffin ezt írta:

...

On 10/8/06, Jason Chu wrote:

...
Instead of checking for /etc/arch-release or /etc/frugalware-release, why not make it an autoconf option? --with-arch-in-filename or something...

That would work too, but I would feel more comfortable with the on-the-fly parsing. I mean, if we decide we want to have the arch name in the file name at a later date, this would allow us to make changes a few packages at a time without breaking things in the least.

Hey there. Please see TODO.autoconf part libalpm and codechanges "topic" I added that line about configure and config.h detection for this. Now the main idea was create some "schema"-based stuff, where we store all values for each distributions. Like how pkg filename will look, whats the cachedir, whats the pkgext, etc.. And then we can do a --with-distro=archlinux --with-distro=frugalware or --with-distro=anything... For new distros wants to use pacman as pkgmanager it is good, because ina schema-based system he can fill out or add files for pacman and can use it with care. I dunno how can be this done in coding, 'cause i not worked on this atm. But if its good idea and fine, then maybe the schema-based / autoconf options will do the work no ? And all specific distro changes contained by one file like: distros/archlinux.h distros/frugalware.h etc. Regards Christian Hamar alias krix

Cameron Daniel

9 Oct 9 Oct

3:25 p.m.

On Sun, 08 Oct 2006 14:11:12 +0200 Christian Hamar wrote:

...

Now the main idea was create some "schema"-based stuff, where we store all values for each distributions. Like how pkg filename will look, whats the cachedir, whats the pkgext, etc.. And then we can do a --with-distro=archlinux --with-distro=frugalware or --with-distro=anything...

And all specific distro changes contained by one file like: distros/archlinux.h distros/frugalware.h etc.

I like this idea, sounds easy to maintain and would be logical if everyone still plans on reaching an agreement to bring the pacman3 CVS up-to-date with the work the Fw guys have done.

Aaron Griffin

10:29 p.m.

On 10/9/06, Cameron Daniel wrote:

...

On Sun, 08 Oct 2006 14:11:12 +0200 Christian Hamar wrote:

...
Now the main idea was create some "schema"-based stuff, where we store all values for each distributions. Like how pkg filename will look, whats the cachedir, whats the pkgext, etc.. And then we can do a --with-distro=archlinux --with-distro=frugalware or --with-distro=anything...

And all specific distro changes contained by one file like: distros/archlinux.h distros/frugalware.h etc.

I like this idea, sounds easy to maintain and would be logical if everyone still plans on reaching an agreement to bring the pacman3 CVS up-to-date with the work the Fw guys have done.

I said it before, but let me explain the rationale as to why I think this is a bad idea. If we decide to use settings and functions for frugalware and archlinux, how many differences will we solve this way rather that actually talking them out and advancing BOTH distros. i.e. if appending the architecture to the end of a package is really that important, why doesn't arch do it? Rather that ifdeffing crap out, why don't we use that scheme if it's better? A lot of projects do the whole #ifdef SOLARIS type code differences, but I can honestly say I've never in my life seen something like #ifdef REDHAT and #ifdef DEBIAN. I think that says something. Will we have to wait until the frugalware.h header has 100 functions defined that are completely different from archlinux.h to say "hey maybe this was a poor idea"? pacman is pacman. It shouldn't be dependant on what distro it runs on.

Roman Kyrylych

10:45 p.m.

2006/10/9, Aaron Griffin :

...

I said it before, but let me explain the rationale as to why I think this is a bad idea. If we decide to use settings and functions for frugalware and archlinux, how many differences will we solve this way rather that actually talking them out and advancing BOTH distros. i.e. if appending the architecture to the end of a package is really that important, why doesn't arch do it? Rather that ifdeffing crap out, why don't we use that scheme if it's better?

...

Will we have to wait until the frugalware.h header has 100 functions defined that are completely different from archlinux.h to say "hey maybe this was a poor idea"? pacman is pacman. It shouldn't be dependant on what distro it runs on.

It would be nice if there were less differences between Arch/Frugalware/<other pacman-based distro> in package management area, but we live in the world which is far from perfect. There _will_ be differences. For example, I doubt that Frugalware will change *.fpm back to *.pkg.tar.gz or eliminate/rename some extensions to PKGBUILDs & makepkg. When there will be more distros they will try to accomodate Pacman to their needs, thus creating branches and maybe even forks. Having such config possibility as described by Christian Hamar is good. I don't say that there shouldn't be standartization initiative for making Pacman-based distros to have similar package management schema, but having a compile-time option is not a bad idea in case there will be no agreement on some topics. P.S.: English is not my native language so please sorry if what I've written here looks messy. -- Roman Kyrylych (Роман Кирилич)

Aaron Griffin

11:02 p.m.

On 10/9/06, Roman Kyrylych wrote:

...

It would be nice if there were less differences between Arch/Frugalware/<other pacman-based distro> in package management area, but we live in the world which is far from perfect. There _will_ be differences. For example, I doubt that Frugalware will change *.fpm back to *.pkg.tar.gz or eliminate/rename some extensions to PKGBUILDs & makepkg.

Well, as far as this goes - this (in the near future) will be available as a configure flag. I don't actually see the extension naming as a distro specific thing, really. There's been talking about changing the archlinux package extension too. With this option, we could easilly switch it with a simple compile (not saying we would). Defining constants in this way is fine and all, but changing FEATURES like this is a poor choice. It's not like we're talking about "256 colors" or not, which aren't supported on all displays. At this point in time, especially with one feature like this, which _can_ be resolved, I see no need to start doing this the messy hackish way i'll call "ifdef FRUGALWARE"

Roman Kyrylych

11:36 p.m.

2006/10/9, Aaron Griffin :

...

On 10/9/06, Roman Kyrylych wrote:

...
It would be nice if there were less differences between Arch/Frugalware/<other pacman-based distro> in package management area, but we live in the world which is far from perfect. There _will_ be differences. For example, I doubt that Frugalware will change *.fpm back to *.pkg.tar.gz or eliminate/rename some extensions to PKGBUILDs & makepkg.

Well, as far as this goes - this (in the near future) will be available as a configure flag. I don't actually see the extension naming as a distro specific thing, really. There's been talking about changing the archlinux package extension too.

I didn't know about this until you mentioned this in your previous message. And what were variants? OK, it's not so important and it's off-topic, but I'm very interested. :-)

...

With this option, we could easilly switch it with a simple compile (not saying we would). Defining constants in this way is fine and all, but changing FEATURES like this is a poor choice. It's not like we're talking about "256 colors" or not, which aren't supported on all displays.

Well, I agree on that. Pacman shoul have the same features regardless of distros. I think there shouldn't be a situationd like these: Arch uses md5, Frugalware uses sha1 (BTW, SHA-512 is even better); Frugalware has extensions to better manage CPAN modules, etc...

...

At this point in time, especially with one feature like this, which _can_ be resolved, I see no need to start doing this the messy hackish way i'll call "ifdef FRUGALWARE"

Do you still talking about pkgname-pkgver-pkgrel[-arch] naming? Can't -arch suffix be made optional? I mean use arch=(...) in pkgbuilds anyway, but allow distro makers to add -arch suffix to package filenames without worrying abut how pacman will eat that. I agree that having "#ifdef FRUGALWARE" stuff is not nice here. -- Roman Kyrylych (Роман Кирилич)

Jason Chu

12:19 a.m.

On Sun, 8 Oct 2006 06:21:27 -0500 "Aaron Griffin" wrote:

...

On 10/8/06, Jason Chu wrote:

...
Instead of checking for /etc/arch-release or /etc/frugalware-release, why not make it an autoconf option? --with-arch-in-filename or something...

That would work too, but I would feel more comfortable with the on-the-fly parsing. I mean, if we decide we want to have the arch name in the file name at a later date, this would allow us to make changes a few packages at a time without breaking things in the least.

I wouldn't feel more comfortable with it. If I had a case where I didn't have an /etc/arch-release or /etc/frugalware-release (I accidently deleted it or I was using pacman.static to make a chroot for a different distro), it's not going to work reliably.

...

...
Trying to guess if the architecture is included in the filename isn't possible reliably. foo-bar-2.4-1 is ambiguous and a pretty common case.

The arch is added at the end in this patch, after the pkgrel, so there is no ambiguity foo-bar-2.4-1-i686 foo-bar-2.4-1-x86_64 etc etc

So we know what valid arch strings are? Currently we parse packages based on the number of dashes. The string after the last dash is the pkgrel and the string after the penultimate dash but before the last dash is the version. In a case where you have a package foo-bar-2.4-1, is the package name foo-bar, the version 2.4, and the pkgrel 1 OR is the package name foo, the version bar, the pkgrel 2.4, and the arch 1? In your example, is that foo-bar-2.4, version 1, release i686? Or foo-bar, version 2.4, release 1, arch i686? Does that mean pkgrel's can never be in the list of arches? It also means we have to update all these scripts as new arches come out. It's not just pacman that has this sort of assumption (ie. the gensync db doesn't store a filename associated with a package, the filename is just $pkgname-$pkgver-$pkgrel.pkg.tar.gz), it's all the supporting scripts too. The ones that create packages aren't that bad (makepkg), but ones that have to take pkgname, pkgver, and pkgrel and create a filename are more trouble (gensync, pacman, pacbuild). Jason

VMiklos

8 Oct 8 Oct

5:14 p.m.

On Sat, Oct 07, 2006 at 11:25:15PM -0500, Aaron Griffin wrote:

...

An ifdef would certainly work, but there's a point where to code is going to diverge too greatly... I mean how many #ifdef FRUGALWARE changes will we end up with.

i hope as less as possible. i'll try to prepare a patch then we'll see :)

...

In some of these cases, we should be able to check, on-the-fly, if it has an arch name or not. I don't know about _all_ of them, but it should be straightforward to actually check.... I need to think about it though. Arch packages do have an architecture value, but it's not used in the package name, so it would be a tad difficult to reconstruct...

of course the on-the-fly approach will work for makepkg, gensync and so on :)

...

I'm assuming there's no way to convince you guys to make extra dirs for your different architectures instead of appending it to the pakcage name, is there? 8)

yes, you're right :) i don't want to flame about this, but two reasons: 1) since only one version of a package is stored in the pkgdb, including the package version and release in the filename would be unnecessary, too (sounds a bit weird :) ) 2) all the other package managers (rpm/deb/slack) includes the architecture in the filename udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Jason Chu

9 Oct 9 Oct

12:22 a.m.

On Sun, 8 Oct 2006 11:14:32 +0200 VMiklos wrote:

...

2) all the other package managers (rpm/deb/slack) includes the architecture in the filename

I've been arguing for the architecture in the filename for a long time... some arch devs are really against the idea and I have no idea why... Usually the best argument they have is that it breaks backwards compatibility and packages in repos should be stored in their architecture's directories. Both of which, I don't buy. I once had an idea to not depend on the filename at all. Instead to get the package's info from the .PKGINFO. Then the filename becomes irrelevant... Jason

VMiklos

2:26 a.m.

On Sun, Oct 08, 2006 at 09:22:17AM -0700, Jason Chu wrote:

...

I've been arguing for the architecture in the filename for a long time... some arch devs are really against the idea and I have no idea why... Usually the best argument they have is that it breaks backwards compatibility and packages in repos should be stored in their architecture's directories. Both of which, I don't buy.

we have them in separate dirs, too. and you can't be backwards compatible forever.. :) the usual practice at us is to to be backwards compatible between stable releases. so after 0.5 was out, the 0.4 -> -current upgrade is no longer supported

...

I once had an idea to not depend on the filename at all. Instead to get the package's info from the .PKGINFO. Then the filename becomes irrelevant...

when you build the list of files to download it still matters imho udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Jason Chu

2:34 a.m.

On Sun, 8 Oct 2006 20:26:15 +0200 VMiklos wrote:

...

...
I once had an idea to not depend on the filename at all. Instead to get the package's info from the .PKGINFO. Then the filename becomes irrelevant...

when you build the list of files to download it still matters imho

Only if gensync doesn't store the filename associated with the package in the db itself. If pacman could just look at the db entry and see what the filename is, it wouldn't matter. Jason

Roman Kyrylych

2:59 a.m.

Hi! Can non-pacman-dev-man enter this discusstion? VMiksos said:

...

okay, but then we should hardcore the list of possible arches. or how could we determine of the last item is an arch or a pkgrel?

I don't see a problem here. There're not much archs to deal with, curently only i686 and x86_64. Other distros may implement ppc and maybe some more, but anyway it's not too much to hardcode them. 2006/10/8, Jason Chu :

...

On Sun, 8 Oct 2006 11:14:32 +0200 VMiklos wrote:

...
2) all the other package managers (rpm/deb/slack) includes the architecture in the filename

I've been arguing for the architecture in the filename for a long time... some arch devs are really against the idea and I have no idea why... Usually the best argument they have is that it breaks backwards compatibility and packages in repos should be stored in their architecture's directories. Both of which, I don't buy.

I once had an idea to not depend on the filename at all. Instead to get the package's info from the .PKGINFO. Then the filename becomes irrelevant...

What -i686/-x86_64 will give to ordinary user? Just more chars in every pacman output! If user choose the x86_64 repo then almost all packages will be x86_64 anyway ( some can be for i686 only if there are no correspondent x86_64 versions). -- Roman Kyrylych (Роман Кирилич)

VMiklos

3:57 a.m.

On Sun, Oct 08, 2006 at 09:59:23PM +0300, Roman Kyrylych wrote:

...

Can non-pacman-dev-man enter this discusstion?

why not? :)

...

I don't see a problem here. There're not much archs to deal with, curently only i686 and x86_64. Other distros may implement ppc and maybe some more, but anyway it's not too much to hardcode them.

good question. i hate to hard-wire anything, but this is the decision, then something like #define ALLOWED_ARCHS "i686 x86_64 ppc" looks ok to me (so using such pkgrels will be no longer allowed) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Aaron Griffin

6:09 a.m.

Woah, I think this thread went on a bit of a tangent. Here are my points, rewritten to clarify things. The -arch ending to frugalware packages does not work with arch packages. Currently arch packages do not have this. I have heard no arguments on EITHER side of the fence about why to do this or why not to - and, frankly, this is not the right thread... we can start a new one for that. The point is it breaks things now. Detecting the architecture at runtime COULD be ifdef'd out, but I have a high aversion to: #ifdef FRUGALWARE #else //archlinux #endif It looks messy, and ties pacman in places where it doesn't need it. And once this is an option, how many issues similar to this will later be solved with "just use #ifdef FRUGALWARE" - it's not a good idea to do this... define:spaghetti code As for the actual detection at runtime... well, I didn't mean anything fancy. I actually meant tokenize the filename and split off the last 3 chunks, checking to see which are numeric (pkgrel) or fit something versioncmp understands (pkgver) and setting the arch if we have an extra dangling token. I know this would cause problems with packages named.... package-9-1.0-1, but there are no existing packages like this, and I have a feeling those may break the existing setup. For right now, I have removed these changes... if you guys really want to move to a "-ARCHNAME" suffix, someone start another thread discussing this. Right now I have no reason to make the change, as no one has ever brought this up to me.

VMiklos

6:45 a.m.

On Sun, Oct 08, 2006 at 05:09:49PM -0500, Aaron Griffin wrote:

...

extra dangling token. I know this would cause problems with packages named.... package-9-1.0-1, but there are no existing packages like this, and I have a feeling those may break the existing setup.

we do use non-integer pkgrels (for security support) and "foo-version"-like pkgnames

...

For right now, I have removed these changes... if you guys really want to move to a "-ARCHNAME" suffix, someone start another thread discussing this. Right now I have no reason to make the change, as no one has ever brought this up to me.

okay :) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

Jason Chu

2:17 p.m.

On Sun, 8 Oct 2006 17:09:49 -0500 "Aaron Griffin" wrote:

...

As for the actual detection at runtime... well, I didn't mean anything fancy. I actually meant tokenize the filename and split off the last 3 chunks, checking to see which are numeric (pkgrel) or fit something versioncmp understands (pkgver) and setting the arch if we have an extra dangling token. I know this would cause problems with packages named.... package-9-1.0-1, but there are no existing packages like this, and I have a feeling those may break the existing setup.

So pkgrels can't have letters in them? We used to use -1t1 and -1s1. vercmp has no problem with version/release numbers with letters in them. While it's unlikely that we will actually run into this problem, it is possible. VMiklos said that some of the frugalware packages have longer more alphanumeric pkgrels. Also, how will pacman -Su figure out what the filename is? My understanding (this was from pacman 2) is that pacman takes the $pkgname-$pkgver-$pkgrel from the gensync'd db and tries to download the file based on that. Will we make two requests for each file? One for $pkgname-$pkgver-$pkgrel.pkg.tar.gz and one for $pkgname-$pkgver-$pkgrel-arch.<whatever frugalware ends with>? Jason

6416

Age (days ago)

6418

Last active (days ago)

List overview

Download

21 comments

6 participants

participants (6)

Aaron Griffin
Cameron Daniel
Christian Hamar
Jason Chu
Roman Kyrylych
VMiklos