Changelog.txt in Slackware -> where's the AL alternative?

puntmuts · 2005-04-05 21:48:16

Hello fellow Archers,

In the few weeks I'm using AL now, there is one thing I miss and would like compared to Slackware. Slackware, had this changelog.txt on the website and the ftp where you could find the changes and what the changes were. These changes were mainly about security fixes, updates, addition or removal of software.

Using AL, there is no way of knowing (or I did not discover a way) what a next release/update will bring and what was the reason for it. Even when you decide to download the packages and not install them right away it might be a good idea to read the changelog to see what is important and urgent (major security fixes) or less important. That way you could choose to install software or keep using the version you run without problems. I know there are wiki entries containing information about for example KDE, but these do not exist for every single package.

There are some ways of doing this:
- a dedicated mailinglist with package announcements and changelogs
- a file included in the package
- an announcement in a seperate forum
- some centralized solution like Slackware has (one maintainer)
- on the website seperate indication for update type (Sec/Norm/??)
- some of the above
- all of the above

Did I miss something or does something like this does not exist for AL ? And if not, how do you think about this changelog idea ?

Cheers.

phrakture · 2005-04-05 21:50:10

there's a newsletter released every so often which contains new packages and version updates....

puntmuts · 2005-04-05 21:58:19

Some weekly or monthly news which is published on the frontpage ? That is hardly sufficient for keeping track of security updates

Or do you mean some other newsletter ?

phrakture · 2005-04-05 22:05:14

nope that was it - but keep in mind there is no differentiation between types of updates in arch - an update is an update is an update....
if there is a security hole in some app, *usually* the devs release a new version when the hole is made public... at which point the packagers will release the new version...

you need to understand that most packages are tested before they go out... you want some feature like this so you can "choose to install software or keep using the version you run without problems" - yet that is entirely against the arch philosophy... the arch philosophy is to keep your system updated...

now if you're running a production box and want a feature like this, you shouldn't be relying on the package maintainers for arch - you should be maintining your own local mirror so you can manage this sort of thing yourself.... you can't expect the arch packagers to make sure your server is up and running fine (RH does this and charges and arm and a leg)

puntmuts · 2005-04-05 22:15:31

I know that I should update my system on regular basis but I like to wait a couple of days / week or so for my server. I test the software on my desktop machine and when that is running without a problem I update my server as well. Unless it is a security update, then I install it immediately on both machines (like the latest php version).

But it would be handy and nice to know before installing what is a security update and what not without the need to find the webpages of the package involved but have a standard way of knowing/looking for it.

I have an exim email server for example and would like to know as soon as possible if there is a security problem. In this case I already subscribed to a mailinglist of exim which informs me when a new version is released and what the changes are. But I don't want to subscribe to such a list for every package I use . That's why I would like some information about a package release before installing it

phrakture · 2005-04-05 22:21:08

puntmuts wrote:

I have an exim email server for example and would like to know as soon as possible if there is a security problem. In this case I already subscribed to a mailinglist of exim which informs me when a new version is released and what the changes are. But I don't want to subscribe to such a list for every package I use . That's why I would like some information about a package release before installing it

An important thing to note here: you don't want to subscribe to a ML for every package you use.... neither do the maintainers... there's like 10 of them... you think they have time to go and research why each package they own was updated and write a blurb on it? I sure don't...

I know, for the most part, I don't care when readline gets updated, or aterm, or wesnoth... and I wouldn't want the packagers taking time out of their day to write up "hey wesnoth was updated today, 3 new sprites were added, and now the elves can have machine guns!"...
when there's some major change ("damn, I gotta re-download kdelibs, wtf?") then I check it out myself...

I can see your point about security updates and all, but it's not like these guys are getting paid... why don't you take the initiative and start doing a changelog writeup, I'm sure people would appretiate it

puntmuts · 2005-04-05 22:35:18

Well basicly the maintainers of a package are the ones who know what did change in the package. I'm proposing some very simple ways to provide this information. A simple flag would be sufficient, is it a security related release or not. And if I were a package maintainer I would be subscribed to those lists. I did when I used non standard software on Slackware. And when I read about a security fix for a certain package I will flag it out of date if not already done by someone else.

But to make some kind of changelog of the complete AL repository takes a lot of time what I don't have right now.

And yes I know AL is a community based distribution and the maintainers are volunteers. But I think it will be an improvement and worth the extra trouble.

cactus · 2005-04-05 23:16:49

The front page of archlinux.org has an rdf feed with updated packages. The only thing lacking is a despription of what the update was.

If security is THAT important to you, then you shouldn't be relying on the devs to rebuild critical packages. You should be doing it yourself.

That being said, I don't know how much extra work would be involved with putting the cvs changelog information into the rdf feed that sits on the archlinux.org site. The cvs changelog should have information about why the package was updated (and is attached to the pkgbuild).

Stemming from somthing like.

cvs -m "Updated due to bug in foo:bar" package/PKGBUILD

shouldn't be too hard to snag from anonymous cvs for the rdf feed..

puntmuts · 2005-04-11 08:26:46

Too bad that AL does not have anything of a changelog or security update notification. Almost any distribution has a mailinglist / webpage with security updates and it makes it easier for users to update their systems and keep them safe.

Maybe I should use something else for server purposes, I do not have the feeling security is an serious issue at AL.

cactus · 2005-04-11 08:46:06

puntmuts wrote:

Too bad that AL does not have anything of a changelog or security update notification. Almost any distribution has a mailinglist / webpage with security updates and it makes it easier for users to update their systems and keep them safe.

AL just has a diferent philosophy. With no real "release schedule", and using rolling releases, it is hard to track a changelog. Security update notifications would be a good thing though. Right now there is just a lowly forum topic, and several of the devs never visit the forum, so likely it is only useful for users discussing issues they find. A few security notices come up on the main site, but I agree that doesn't really "cut" it.

It would be nice to have a security mailing list, where the devs put out notices and such. Then it would be easy to just look at the mailing list archive, and see what is going on..or to subscribe to the list..etc etc.

Maybe I should use something else for server purposes, I do not have the feeling security is an serious issue at AL.

I think the last statement you made is the most important. It is really about how you FEEL. I feel relatively fine with my server setups. I have them locked down fairly well, and since they don't really do alot right now, I am not overly concerned with their current status. Arch makes a great devel box too. So, for me, it is ok.

If I needed 3 or 4 9's worth of uptime, and had lots of important data running around on my servers, I would likely go for something like RH or SuSE. Something that has LOTS of upstream testing. Maybe debain, or one of the BSD's.

If you do not feel comfortable with it, then by all means, use something that you DO feel comfortable with. No sense laying awake at night worrying about your data.

I personally am starting to view Arch as more of a development environment (which is great because things are so up to date), and as a decent desktop (again, good because of up to date, and for me desktop==dev box). It is also damn fun for geeking out on. I cant tell you how many obscure things I have tried to do on my arch boxen..lots of good geeking around (like. Can I build a pkgbuild for this? and..can I get this to work? etc.)
I am not sure it would be my first choice in a critical production environment, though.
*shrug*
But then again, who knows. It would depend on the situation..

puntmuts · 2005-04-11 12:46:04

Thanks for your reply, cactus

First of all, I like AL a lot. That's why I will keep using it on my desktop machine. But for server purposes I will look for a different approach, the moving thing is not my idea of handling security and stability required for a server. Even the 2.6 kernel , which used a comparable development strategy, has some kind of stable versions nowadays.

But we do not disagree about this

iphitus · 2005-04-11 13:58:36

Im running the Arch Release on my server atm

so far

[iphitus@server ~]$ uptime
 06:09:21 up 1 day, 12:29,  1 user,  load average: 0.00, 0.00, 0.00

But I only installed it a day ago

puntmuts · 2005-04-11 17:26:30

My server uptime currently is about 27 days, that's not the issue here..

Arch Linux

#1 2005-04-05 21:48:16

Changelog.txt in Slackware -> where's the AL alternative?

#2 2005-04-05 21:50:10

Re: Changelog.txt in Slackware -> where's the AL alternative?

#3 2005-04-05 21:58:19

Re: Changelog.txt in Slackware -> where's the AL alternative?

#4 2005-04-05 22:05:14

Re: Changelog.txt in Slackware -> where's the AL alternative?

#5 2005-04-05 22:15:31

Re: Changelog.txt in Slackware -> where's the AL alternative?

#6 2005-04-05 22:21:08

Re: Changelog.txt in Slackware -> where's the AL alternative?

#7 2005-04-05 22:35:18

Re: Changelog.txt in Slackware -> where's the AL alternative?

#8 2005-04-05 23:16:49

Re: Changelog.txt in Slackware -> where's the AL alternative?

#9 2005-04-11 08:26:46

Re: Changelog.txt in Slackware -> where's the AL alternative?

#10 2005-04-11 08:46:06

Re: Changelog.txt in Slackware -> where's the AL alternative?

#11 2005-04-11 12:46:04

Re: Changelog.txt in Slackware -> where's the AL alternative?

#12 2005-04-11 13:58:36

Re: Changelog.txt in Slackware -> where's the AL alternative?

#13 2005-04-11 17:26:30

Re: Changelog.txt in Slackware -> where's the AL alternative?

Board footer