Arch Linux 0.7.1 - my feedback

Virtual DarKness · 2006-03-19 00:36:35

please read the post before vote

--

Well, I've used Arch linux for many months in late 2004 / early 2005 and then I've switched to Ubuntu...

some days ago I've installed version 0.7.1 and updated it with pacman -Syu

I've seen a lot of improvement since the last time I used it and I was near to think "ok let's switch back to Arch" until I found I that thing I really hate :!: is still here..

You can't install old versions of some packages. For example, kernel.. or.. php (ok there is one in Aur that is maybe "too" old) and mysql..

in the php/mysql example it's true that version 5 is the latest one but they (at least php) still develope the 4.x version for security and many server still have it and also many scripts supports only php4 and 5.

also, as I am a php developer, I need to test scripts with old versions.

but as I said this is just an example. I think that while you can't think to have a big repository of binaries it would be great to be able to install old versions via source.

and recompiling software by hand using old PKGBUILDS is a problem case you don't have a tool that tells you wich packaged were "aligned" with wich.. I mean.. the new php works only with the mysql5 extension so even if you build mysql by yourself it won't work with php.. and so on for apache..

anyway.. if a user is able to block a package and prevent the automatic update he should also be able to use the non-latest version of it.

I know that arch is a bleeding edge distro but this shouldn't mean that you have only the bleeding things. (see gentoo for example)

Another thing that will help a lot in my opinion is to have in the wiki 2 lists:

- one very detailed with available daemons and their use.. for example.. ok.. fam is the file alteration monitor.. but why you need it and wich are the main programs that takes advantage from it and what happens if you doesn't run it? and so on for hal, etc. ..

- one list with all available standard groups that tells user to wich group subscribe in order to be able to performe a specific action

imho this 2 lists will help the (new) user understand better what is doing and why The arch philosophy of "do it yourself and learn doing it" is great but have to be encouraged, and in fact there already is a very good documentation.

Just my 2 cents. And sorry if some one else already said this before; in this case take my post as an underline mark btw.. I'll attach a poll to it.

bye,
Giovanni.

Dusty · 2006-03-19 00:57:06

Nice post! I'll address some concerns.

Virtual DarKness wrote:

You can't install old versions of some packages. For example, kernel.. or.. php (ok there is one in Aur that is maybe "too" old) and mysql..

I get the feeling you know all the following, but for completeness:

- You can make your own packages using makepkg at any time, even if they aren't in AUR
- You can get 'old' PKGBUILDs from the cvs interface on archlinux.org front page.
- Somewhere in the 'long-term' todo list is package rollback functionality. This isn't the same as multiple versions of packages though.

anyway.. if a user is able to block a package and prevent the automatic update he should also be able to use the non-latest version of it.

These are two totally different problems though, as far as trying to implement the one from the other. For the most part, Arch contains all the functionality you need to have multiple packages. The problem is most packages install to the same location, so its hard to keep them from conflicting. That entails a lot of maintenance overhead which I can guarantee the devs don't have time for. Users may, however.

Another thing that will help a lot in my opinion is to have in the wiki 2 lists:

I love wikis!! You're certainly welcome to add these things. :-) If they aren't complete, its ok, people may add to it later.

Does Ubuntu allow multiple versions of packages to be installed, in general? The only way I can think of it being possible is to give every binary, library, and shared directory a unique version. Doesn't seem like something that can be implemented genericaly to me...

Dusty

Virtual DarKness · 2006-03-19 02:28:42

Dusty wrote:

- Somewhere in the 'long-term' todo list is package rollback functionality. This isn't the same as multiple versions of packages though.

anyway.. if a user is able to block a package and prevent the automatic update he should also be able to use the non-latest version of it.
These are two totally different problems though, as far as trying to implement the one from the other.

mh I mean.. that if you block a package to prevent the automatic update you should be also be able to obtain the old version if this is your first install; but it is true that for this users can use the stable version they find on the release cd.

For the most part, Arch contains all the functionality you need to have multiple packages. The problem is most packages install to the same location, so its hard to keep them from conflicting. That entails a lot of maintenance overhead which I can guarantee the devs don't have time for. Users may, however.

mh actually I didn't meant to keep more version of the same software installed at once.. this would be good too but I mean just to have the old version instead of the latest at least compilable using source (that will be like a "backport" cause it will allow to build against new deps I think).

I love wikis!! You're certainly welcome to add these things. :-) If they aren't complete, its ok, people may add to it later.

my first idea was to do it but would be better to start is a collective work from the beginning with a discussion on the "Forum, Wiki and Documentation Discussion" forum.. but now that fact of not being able to have old version have a bit "demotivated" me :oops:

Does Ubuntu allow multiple versions of packages to be installed, in general?

yeah I can select if to have php4 or php5 and the same for mysql. You also have apache 1.3 (from debian) :!: but you can't have both php4 and 5 at the same time I think.

bye,
Giovanni.

edit:
if you are voting that there is no need of old version keep in mind that I'm not talking about the old version of gimp or gaim but of some core components of a system / server that are crucial into a work / productive environement. In some cases a old version of (let's say) gaim could have a plugin that is not in the new one but more often happens that the new version of gaim fixes some connection problem or so on. This is not the same for the "core" software I was talking about when often is better to have a more old version than the latest.

iphitus · 2006-03-19 02:35:25

Virtual DarKness wrote:

For the most part, Arch contains all the functionality you need to have multiple packages. The problem is most packages install to the same location, so its hard to keep them from conflicting. That entails a lot of maintenance overhead which I can guarantee the devs don't have time for. Users may, however.
mh actually I didn't meant to keep more version of the same software installed at once.. this would be good too but I mean just to have the old version instead of the latest at least compilable using source (that will be like a "backport" cause it will allow to build against new deps I think).

Dusty wrote:

- You can make your own packages using makepkg at any time, even if they aren't in AUR
- You can get 'old' PKGBUILDs from the cvs interface on archlinux.org front page.

You can have the old versions, you can compile them from source.

Either find a PKGBUILD in the AUR, or get an old version of a repository package at Arch's CVS interface.

Virtual DarKness · 2006-03-19 02:43:59

iphitus wrote:

Either find a PKGBUILD in the AUR, or get an old version of a repository package at Arch's CVS interface.

yes I know this but is not so easy.. I mean.. I've compiled mysql 4 in the way you described but then I had no mysql module in php... so I'd have to recompile also php and look for wich was the last version to support mysql4.. and at this point some problems may raise with the php module in apache.. and so on

that's what I meant with "you don't have a tool that tells you wich packaged were "aligned" with wich".

and going more "harder" than this would mean say "compile it by yourself from scratch" but this isn't about package management

bye,
Giovanni.

p.s.
and keep in mind that my situation is about php/mysql but this are problems that could rise also with other packages.. I mean: I don't aim to fix this specific problem; it's a more generic thing.

ibrahim · 2006-03-19 08:28:40

As far as installing multiple versions of something, in debian based systems you can use dpkg-divert which will change where the package manager installs files to e.g. mplayer in future might go to /usr/bin/mplayer.ibrahim in order to leave untouched your custom build at /usr/bin/mplayer.

I'm not read up on too much detail of how pacman works but could something similar be possible by creating an alternate entry in the database?

edit:
Actually I would think that the database is really just a list of what is installed, the packages would still be in the same bin directory so I assume it wouldn't be the databse that needs adjusting

tomk · 2006-03-19 10:03:46

Well, I voted "No, there is no need", because I think this is simply an indication that Arch is not the right distro for you - it doesn't meet your requirements. If you want to use Arch, and you must have this functionality, submit a feature request, or even write the apps/patches/whatever required to implement it, and it might make it into a future version.

This "thing that you really hate" is still there because firstly the Arch devs, and secondly Arch users, have not needed to change it. If you want to work "from within" to change that, with polls like this, feature requests, etc, I wish you the best of luck, but I think your poll result so far should tell you something about the support you can expect.

Finally a general point, and this applies to wiki entries as well - you will get a better response if you do something, and then ask "what do you think?" instead of asking "Why doesn't Arch do this?". As an example, around the time we switched to gcc4, there were a bunch of threads asking for gcc3.x to be retained, and one thread with a gcc4/gcc3.x in parallel howto. If I'd needed this, I know which thread I'd have gone to.

Chris|MD · 2006-03-19 11:24:33

Yes!
For Example Flex-old which is needed for building Cedega-cvs.
So easy to get under Debian/Gentoo.
Compiling from source is okay but if you dont know how to edit the PKGBUILD or even create one you could prevent some things from running because they are mixed up, are installed in the same folder and dont run because old needed libraries miss too.

iphitus · 2006-03-19 12:29:55

To me this thread looks more like "i dont want to make a second package for myself, so let's get the devs to do it". Quite frankly, there's much bigger, and much more important things to worry about. Especially as there isnt a huge demand for such a package, and you are most likely to be one of a very small minority to use that duplicate package. This is one of the areas which the AUR should shine, making available some such PKGBUILDs.

iphitus

/end personal opinion and not that of the dev team in any way.

Sander · 2006-03-19 13:15:31

besides, the reason you are able to install both php4 and php5 is because they are effectively different pieces of software... comparable to the GTK / GTK2 situation, I think.

I don't think it'll let you install PHP 4.3.0 and 4.4.0 along side. Or does it?

Virtual DarKness · 2006-03-19 13:27:29

iphitus wrote:

To me this thread looks more like "i dont want to make a second package for myself, so let's get the devs to do it".

hmm.. this sounds a bit offenisve to me. Cause I don't actually need that packages as I'm not using Arch as main distro. This post was meant to give a feedback..

iphitus wrote:

Especially as there isnt a huge demand for such a package, and you are most likely to be one of a very small minority to use that duplicate package.

ok I agree with this. but from my point of view it is because users that needed it too already switched to another distro..

and this leads us to this:

tomk wrote:

I voted "No, there is no need", because I think this is simply an indication that Arch is not the right distro for you - it doesn't meet your requirements.

Imho, the point is that Arch have a lot of great features. The one I'd like to have is a feature that I think will just increase the number of great features Arch already have and will make Arch the right distro for more users. So users that switch to another distro will lose a lot of features that they like to get one or two that they need..

tomk wrote:

This "thing that you really hate" is still there because firstly the Arch devs, and secondly Arch users, have not needed to change it. If you want to work "from within" to change that, with polls like this, feature requests, etc, I wish you the best of luck, but I think your poll result so far should tell you something about the support you can expect.

the poll was mainly for myself to get an idea of the users opinion not to change the things. And as I said it is not a change from my point of view, but just a new feature. About Arch devs I agree but about users I don't.. how you can say it if you say to me that I should change distro? In this way people that thinks like me will always remain a minority in arch community. And I don't think that having a old version of a "core" package would be against the Arch philosophy.

tomk wrote:

Finally a general point, and this applies to wiki entries as well - you will get a better response if you do something, and then ask "what do you think?" instead of asking "Why doesn't Arch do this?"

I did it for the software thing with the poll and anyway also for the wiki I didn't wrote it but I thought it was clear.. For the wiki I posted my idea and there was no need for the question "what do you think" cause is a discussion forum Also please keep in mind that I wrote the original post in late night and that I'm italian so my english isn't so good :oops:

anyway.. thanks for the tip about subit a feature request and for your answers.

bye,
Giovanni.

tomk · 2006-03-19 14:09:03

Virtual DarKness wrote:

About Arch devs I agree but about users I don't..

If many Arch users want this feature, why don't we hear about it more often? Where are the relevant feature requests, user contributions, etc?

Virtual DarKness wrote:

how you can say it if you say to me that I should change distro?

I suggested changing distro as one option - I also encouraged you to raise requests and make contributions, which is another option.

Virtual DarKness wrote:

And I don't think that having a old version of a "core" package would be against the Arch philosophy.

The Archlinux Introductory Wiki Page wrote:

Arch Linux strives to maintain the latest stable version of its software. We currently support a fairly streamlined core package set with a growing collection of extra packages made by users and AL developers.

Virtual DarKness wrote:

I did it for the software thing with the poll and anyway also for the wiki I didn't wrote it but I thought it was clear..

As per my gcc example, I meant if you have a need for some-app-1.0 from two years ago, alongside the very latest some-app-3.5, do it on your own system, post a howto, and see what response you get. Same with wiki ideas - write it up, and see how it goes down.

jaboua · 2006-03-19 15:19:43

You can find and install older packages from /var/cache/pacman/pkg if you've installed them before

IMO, no need.

iphitus · 2006-03-19 15:51:19

Honestly, I am yet to see a valid reason why the user cannot make such a package themselves.

There is definitely a very low demand for these packages, and thus, these packages dont really warrant the developers time. The users of these packages are well and truly in the minority.

The least a user could do, if they needed such a package is to make it themselves and upload it to the AUR.

Virtual DarKness wrote:

hmm.. this sounds a bit offenisve to me.

I dont see anything offensive about it. I've yet to see a valid argument contrary of that point.

ok I agree with this. but from my point of view it is because users that needed it too already switched to another distro.. Wink

Got any numbers? Again, by the nature and limited uses of these packages they are low in demand. If these users really wanted to use Arch, they would have made one themselves, as imho is, the arch way.

Ultimately, sure someone might find them useful, but hell, the developers have bigger and more important things to worry about, things that have more than a handful of users.

iphitus

Virtual DarKness · 2006-03-19 17:02:56

@jaboua: I was talking about a quite fresh install situation

@iphitus and tomk: thanks for your last answers. Now I can better understand what you mean.

Now, I've another idea: another AUR category that like unsupported is not used by pacman but just provides PKGBUILDs .. that could be called oldstuff or legacy or what is the best in english

then when you (developers) move a package from testing to current you also move/copy the old pkgbuild and the pkgbuild of the deps into the oldstuff category of AUR.

This way you don't have to search by hand into the cvs site for all matching PKGBUILDs and is also something that should be very quick to mantain.. cause it could just be a flag from specific packages that developers sets if they think that someone could have the need of the old version.

What do you think about this?

bye,
Giovanni.

Euphoric Nightmare · 2006-03-22 15:53:25

Virtual DarKness wrote:

Now, I've another idea: another AUR category that like unsupported is not used by pacman but just provides PKGBUILDs .. that could be called oldstuff or legacy or what is the best in english
then when you (developers) move a package from testing to current you also move/copy the old pkgbuild and the pkgbuild of the deps into the oldstuff category of AUR.
This way you don't have to search by hand into the cvs site for all matching PKGBUILDs and is also something that should be very quick to mantain.. cause it could just be a flag from specific packages that developers sets if they think that someone could have the need of the old version.
What do you think about this?
bye,
Giovanni.

I don't see how that would be an improvement. I mean, makepkg is quite simple. Why would we need a seperate repo for older packages when it's just as simple to make your own package from the pkgbuild.

And this isn't exactly an everyday task, like updating, or syncing. I've had to do that maybe once, if that, and I don't imagine many other people doing it very often either.

If its that big of a problem just write a script that will do it for you...

phrakture · 2006-03-22 16:50:12

Oi oi, flame war!

Just tossing my 2 MHz in here, but it looks like iphitus and tomk got the gist of it before I did.

This is one of those recurring things that comes up, and here's how it goes (I mean no offenses to the OP):
Someone installs Arch for the first time, and says "wow, this is great except for this, this, and that." They then join the forums and post "let's change this" (hell, my first post was about possible changes to pacman functionality).

Now, that's all fine and dandy, and wholely in the spirit of Open Source. However, there is typically a lack of understanding on the part of the Arch philosophy in general. When you come across a feature that *you* think is important, you should take a step back and say "OK, I want it this way, but why doesn't anyone else complain? How do *they* do it?"

In this case, it's already been said. Anyone who wants old versions can use ABS and makepkg to compile it in like a minute (minus compile time, of course). If there is a significant rift in usage/features/whatever, old packages *are* provided. For instance, sqlite2/sqlite3. gtk1 and gtk2. There are many cases.

test1000 · 2006-03-22 17:20:10

iv'e read this entire thread and i _do_ see VD's problem.. it's very specific: He needs old versions of php, mysql and apache because of his needs as a developer.

Now he could have done a number of things to get these programs.
1. If he had already installed those old versions which he needed he could just do a ls /var/cache/pacman/pkg/ and installed those old packages with a pacman -U old_pkg*.

2. if he had not installed them from before he could have visited the CVS and pulled out a PKGBUILD and necessary install files from a reasonable date and compiled the apps.

and as phrakture points out, a lot of old packages are already provided for situations like VD's.

so in conclusion: Arch "philosophy" already takes care of this "problem"(except perhaps needing better documentation so everyone know they can do these things) BUT not for *all* packages as seen by VD's need.

Now *unless* putting every package that users might need old versions of in the current repo(like now) would be too messy and chaotic, then maybe it would be better solved if maintainers of the current repo just placed old versions with significant rift in usage/features/whatever into the old_versions repo instead; which would also be more transparent to the user and make the arch maintainers more aware of this policy.

test1000 · 2006-03-22 17:40:17

i just saw the poll and i have to say the people who vote "No, would require too much effort to mantain" doesn't really get it. It wouldn't require any effort to "maintain" as the packages would go into the old repository and just stay as they are there. The effort needed to get 'em in there would be for the maintainer to think for something like 5secs to a minute whether or not other packages depend on that specific version of a package or similar and then deducing for themselves wether or not it would be worth it to move it to the old_packages repo. That's it.

cactus · 2006-03-22 18:27:23

Another option in the poll might have been: "Yes, In a private repository"

test1000 · 2006-03-23 00:09:53

no. read my post again for why not.

Romashka · 2006-03-23 07:55:23

IMO the idea of having old versions of packages is not so bad, but only for packages with really significant changes between major versions. Most of those packages are usefull for developers and hosting providers.
But it will require some maintainance. Because old versions still receive bugfixes, i.e. there are PHP 5.1.x, PHP 5.0.x and PHP 4.4.x, and all of them receives bugfixes and security fixes. The same is for MySQL and Apache.
So, IMO it would be better if someone volunteers to maintain these old versions, maybe even maintainers of new versions of these packages, if they have time and motivation for this.
How it could be organised? I see few good ways here:
keep old versions in the same repo as new,
move them to [community],
create private repo

test1000 · 2006-03-23 13:14:23

i vote for remove "community" and put its's contents into "extra" and create a new repo called "oldgoodies" (or something ): It would all be more transparent and self-evident for new users...

PJ · 2006-03-23 13:50:30

Romashka wrote:

So, IMO it would be better if someone volunteers to maintain these old versions, maybe even maintainers of new versions of these packages, if they have time and motivation for this.
How it could be organised? I see few good ways here:
keep old versions in the same repo as new,
move them to [community],
create private repo

To me this sounds like AUR. I mean if someone really wants an old package and wants to maintain it, the PKGBUILD could easy be stored in AUR and if enough users are interested in the old version of the package (votes) it would likely be moved to community.

iphitus · 2006-03-23 15:11:46

To whoever in this thread who is wanting these packages. instead of arguing whether or not it's a good idea, go do it, and make a private repo with a pile of this stuff. There's nothing stopping you.

test1000: if only your simplistic views were the way it were. The moment you start getting older software, it may depend on older dependencies. They will cause problems of their own, especially if something else on the system depends on them -- which is quite likely. Other packages will need maintaining, because they're old, doesnt mean theyre immune from security vulnerabilities and bugs, so things like that need to be checked up on and maintained.
And thats if they still compile with the current arch toolchain....
Ultimately, thats going to take more than 5 seconds test1000, and that's not including the build and testing of any such package. I'd like to see apache 1.3 built in <=5 seconds.

iphitus

Arch Linux

#1 2006-03-19 00:36:35

Arch Linux 0.7.1 - my feedback

#2 2006-03-19 00:57:06

Re: Arch Linux 0.7.1 - my feedback

#3 2006-03-19 02:28:42

Re: Arch Linux 0.7.1 - my feedback

#4 2006-03-19 02:35:25

Re: Arch Linux 0.7.1 - my feedback

#5 2006-03-19 02:43:59

Re: Arch Linux 0.7.1 - my feedback

#6 2006-03-19 08:28:40

Re: Arch Linux 0.7.1 - my feedback

#7 2006-03-19 10:03:46

Re: Arch Linux 0.7.1 - my feedback

#8 2006-03-19 11:24:33

Re: Arch Linux 0.7.1 - my feedback

#9 2006-03-19 12:29:55

Re: Arch Linux 0.7.1 - my feedback

#10 2006-03-19 13:15:31

Re: Arch Linux 0.7.1 - my feedback

#11 2006-03-19 13:27:29

Re: Arch Linux 0.7.1 - my feedback

#12 2006-03-19 14:09:03

Re: Arch Linux 0.7.1 - my feedback

#13 2006-03-19 15:19:43

Re: Arch Linux 0.7.1 - my feedback

#14 2006-03-19 15:51:19

Re: Arch Linux 0.7.1 - my feedback

#15 2006-03-19 17:02:56

Re: Arch Linux 0.7.1 - my feedback

#16 2006-03-22 15:53:25

Re: Arch Linux 0.7.1 - my feedback

#17 2006-03-22 16:50:12

Re: Arch Linux 0.7.1 - my feedback

#18 2006-03-22 17:20:10

Re: Arch Linux 0.7.1 - my feedback

#19 2006-03-22 17:40:17

Re: Arch Linux 0.7.1 - my feedback

#20 2006-03-22 18:27:23

Re: Arch Linux 0.7.1 - my feedback

#21 2006-03-23 00:09:53

Re: Arch Linux 0.7.1 - my feedback

#22 2006-03-23 07:55:23

Re: Arch Linux 0.7.1 - my feedback

#23 2006-03-23 13:14:23

Re: Arch Linux 0.7.1 - my feedback

#24 2006-03-23 13:50:30

Re: Arch Linux 0.7.1 - my feedback

#25 2006-03-23 15:11:46

Re: Arch Linux 0.7.1 - my feedback

Board footer