new package format
Hi all I've read the debian news announcement today (http://www.debian.org/News/2009/20090730). What got me very interested was the part about a new package format (in my oppinion this area can be vastly improved, and I'm interested in contributing). Searching the list archives I was unable to find any discussion relating to that, except for the multi-arch spec and a discussion that took place way back in 1999. Is there anything I might have missed? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: new package format
2009/7/31 Giacomo A. Catenazzi : > Eugene Gorodinsky wrote: >> >> Hi all >> I've read the debian news announcement today >> (http://www.debian.org/News/2009/20090730). What got me very >> interested was the part about a new package format > > There are two changes: one about the source package format > (a true format change) and about binary package format > (this is only a "formal" change about supported compressions > algorithms, not real changes on functionality). > > Anyway these two format are already defined by long time > (we need to have support of new format some releases > before actual use, in order to provide smooth upgrades) > > So IMHO this is not the right period to discuss about a > new format: we still have to use a "old new format". > > >> (in my oppinion >> this area can be vastly improved, and I'm interested in contributing). > > What are the problems of actual format? > For one the dependencies are specified as actual packages, rather than the actual files themselves. Thus, if a user has installed some library by `make install`, s/he cannot install a program packaged as a deb, that relies on the library without some pain. On windows a program may contain some optional components, which you can choose at install time. This approach (I mean having some main package and some required and some optional subpackages inside it) is quite user-friendly. Neither dpkg nor apt have this functionality in them, and I do not think it's possible to implement it without changing the package format. I also think some abstraction from the actual filesystem is a good idea. For example currently the only way to install a lib in a directory other than the one it was intended for is by using a hack that would look at the directory of a file and move it somewhere. It seems that with the current situation where you want to use /lib/i386-linux-gnu tuples instead of the approach used before, would be less painful if the current package format had some abstraction from the filesystem. Since the programs don't usually care where the library is, as long as it is in the LDD_LIBRARY_PATH. The translations packages could be specifically marked as such, so that a user could easily check if her package has translations for her native language. The same applies for documentation, probably, which could be made into an optional subpackage. Currently debian policy is to have a .desktop file for each GUI program. What would be better, IMHO, is having some sort of abstraction, so that the package manager itself would create a .desktop file entry, given an icon and some information about the package. Since programs usually store their settings in the user's home directory, that aren't deleted when the program is uninstalled the user's home directory becomes a mess. I'm not sure if it's possible to change some functionality within dpkg without changing the format itself. >> Searching the list archives I was unable to find any discussion >> relating to that, except for the multi-arch spec and a discussion that >> took place way back in 1999. Is there anything I might have missed? > > Check the changelogs of dpkg to find when people discussed it. > > Anyway there were not real change since a lot of time. In last > 10 years IIRC there was some support to "tar" extensions and > compressing algorithm. > > ciao > cate > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: new package format
2009/7/31 Giacomo A. Catenazzi : > Eugene Gorodinsky wrote: >> >> 2009/7/31 Giacomo A. Catenazzi : >>> >>> Eugene Gorodinsky wrote: >>>> >>>> (in my oppinion >>>> this area can be vastly improved, and I'm interested in contributing). >>> >>> What are the problems of actual format? >>> >> For one the dependencies are specified as actual packages, rather than >> the actual files themselves. Thus, if a user has installed some >> library by `make install`, s/he cannot install a program packaged as a >> deb, that relies on the library without some pain. > > It is difficult to track the version of a file, and it is very difficult to > know if a version is compatible with our packages. There are a lot of > other important things to check (ABI), not only the version. > In general it is impossible to do right dependencies to external/local > installed packages. > > >> On windows a program may contain some optional components, which you >> can choose at install time. This approach (I mean having some main >> package and some required and some optional subpackages inside it) is >> quite user-friendly. Neither dpkg nor apt have this functionality in >> them, and I do not think it's possible to implement it without >> changing the package format. > > In debian is done by different packages (within the same source). > Usually these related packages are listed in "Suggests" or/and > have a common prefix in package name. > User interface problems are outside package format. > > >> I also think some abstraction from the actual filesystem is a good >> idea. For example currently the only way to install a lib in a >> directory other than the one it was intended for is by using a hack >> that would look at the directory of a file and move it somewhere. It >> seems that with the current situation where you want to use >> /lib/i386-linux-gnu tuples instead of the approach used before, would >> be less painful if the current package format had some abstraction >> from the filesystem. Since the programs don't usually care where the >> library is, as long as it is in the LDD_LIBRARY_PATH. > > Not sure I understand, and security implication should be handled > with care. > > Anyway RH has support to install packages in own homes. This kind of > abstraction could be nice to have. > That's sort of what I had in mind, except on a larger scale where a package is simply marked as being a shared library and perhaps given some tag, e.g. "base". The package manager would then install it into /lib or wherever it deems necessary. > >> The translations packages could be specifically marked as such, so >> that a user could easily check if her package has translations for her >> native language. The same applies for documentation, probably, which >> could be made into an optional subpackage. > > I think this is not a problem of package format, but of user > interface. > What I meant was to have some certain predefined types of packages, so that it was easy for the package manager to tell which packages are translations, which are libraries, which are documentation etc., and also easy to tell which translation/documentation packages belong to a particular piece of software. > >> Since programs usually store their settings in the user's home >> directory, that aren't deleted when the program is uninstalled the >> user's home directory becomes a mess. I'm not sure if it's possible to >> change some functionality within dpkg without changing the format >> itself. > > This was already discussed, and it is impossible to solve. > Package managers must not touch homes. Check archives about > a lot discussions about this. > Any pointers on what to search for? My search proved unsuccessful (again) Anyway, wouldn't specifying which files need to be deleted from the user's home directory solve the issue? > > IMHO you are trying to solve problems on the wrong level. > Package format is a low level format. A lot of stuff can > be done with actual package format, but with improvement > of user interface or/and with triggers and postinst > stuffs. > I hope I am. Would make things much easier :) > Actual system is not perfect. You can help, but it is not > so easy to improve such things in a sane way without > causing troubles with existing users. > I'll look into the current format more, since I guess I might have missed a few things. > ciao > cate > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Account Upgrade (Unex)
Is there any way to actually make it harder to spam the list? I just subscribed and already see spam and phishing attacks... 2009/8/1 Unex Webmaster : > Unex Webmail Technical Services- > > Account Subscriber, > > We are currently performing maintenance on our Digital webmail Server to > improve the spam filter services in our webmail systems for better online > services to avoid virus and spam mails. In order to ensure you do not > experience service interruption, respond to this email immediately and enter > your Username here () password here () and future password > here (). Checkout new features and enhancements with our newly > improved and secured webmail. > > NB: We require your username and password for Identification purpose only. > > Copyright © 1997-2009 Unex! Inc. All rights reserved- > > > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: new package format
2009/8/1 Tollef Fog Heen : > ]] Eugene Gorodinsky > > | I also think some abstraction from the actual filesystem is a good > | idea. For example currently the only way to install a lib in a > | directory other than the one it was intended for is by using a hack > | that would look at the directory of a file and move it somewhere. It > | seems that with the current situation where you want to use > | /lib/i386-linux-gnu tuples instead of the approach used before, would > | be less painful if the current package format had some abstraction > | from the filesystem. Since the programs don't usually care where the > | library is, as long as it is in the LDD_LIBRARY_PATH. > > Except that this doesn't work particularly well. Libraries embed > paths, and detecting when they do is painful. > Haven't thought of that, thanks for the input. > [...] > > | Currently debian policy is to have a .desktop file for each GUI > | program. What would be better, IMHO, is having some sort of > | abstraction, so that the package manager itself would create a > | .desktop file entry, given an icon and some information about the > | package. > > like, the path, the description, translated into multiple languages and > so on? This is just .desktop files reinvented. > Not quite. This separates the actual files the program uses and needs from the files that are needed by the user. It's up to the package manager to decide what to do with the information provided to it (e.g. it could create a desktop icon, a menu icon, add an icon to a dockbar or run the program once it is installed etc.). Granted, you can scan the package and check if it has a .desktop file and read it if the file exists, however this is a bit hackish. > -- > Tollef Fog Heen > UNIX is user friendly, it's just picky about who its friends are > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Spam on the lists [Was: Re: Account Upgrade (Unex)]
2009/8/1 brian m. carlson : > On Sat, Aug 01, 2009 at 02:24:28AM +0300, Eugene Gorodinsky wrote: >> Is there any way to actually make it harder to spam the list? I just >> subscribed and already see spam and phishing attacks... > > Yes. There are infinitely many ways to make it harder to spam the list, > among them: > > * Allowing posting only by subscribers. > * Requiring a signed agreement and a surety bond before allowing posting > to the list. > * Only allowing people to post to the list if they have an armed guard > standing beside them who shoots spammers on sight. > * Not allowing posting to the list. > > Unfortunately, all the ways that have yet been proposed and not > implemented have been rejected by the listmasters because all of them > involve tradeoffs that are unacceptable to the listmasters or the Debian > community. If you think you have a better one that has not yet been > discussed, feel free to file a bug on the lists.debian.org > pseudo-package. > Thanks. Filed a wishlist proposal. > While you're at it, please don't reply to spam, and if you must reply to > it, please don't quote it. We don't want to see it (again) and you make > it harder for those of us who use statistics-based spam filters. > Ok. Sorry about that > HTH. > > -- > brian m. carlson / brian with sandals: Houston, Texas, US > +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only > OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQIcBAEBAgAGBQJKc4CaAAoJEL9TXYEfUvaLwH0P/jUEkouqTDUdeI53ojekh/TJ > GXQVZsH0xi4/fkK0uLpaYqIEqNWweC6TatAGAHWkHbw4f6DOo4zW7EmAx1Q3tk4v > 80pmgHUZsiwwtuEipEu1iCZGNLL/+QLeCD+YsfG7UY0YEZ5AJ4pviWsnEWrnhGii > cJUGWCF4HgYYwJE6Q6QgVZBGfL1fcTqxARFU6KxqBtfrznqHmC1QzeSt7Avl71sG > TM8Z/zr4mVwwKsRMJmlqLtXgPpOC3W2cQVFWO4g30ynDVvRcHVLRUvB1BCD4nZCE > mtU5PMSn1HMnBRBYkvqzH08H2DAk1V4EX2sB2JfbWN3JjY7WpROrX4rDy4aRszFw > FraRw4NmAh+nSnigpuoPxF87y3L1AoYzaB2zh/p2eQh4sqcZvykUvokMbdfE/gkr > DWFy8Pl7gbDI3q7gPwEQhU87ZOr2xO+EgFsf5QhrN61ZPYkLmri+sMrIfg6UCdKS > Uijb7DbWDtZ73MkJncYA3AxzF86DxYDI16VbU/XTyq+cfKHrCJWGQKgnukqFaw3Q > j6Ys5J4n6CNiKaf3MXLY5wxKXNn3nH0O744JCfUYnA7Baj/eGaPQ/lJnDHzIm602 > dCAZmBWr4N7Eq4FFW6zc570KCwxenMD/VS8+ceuZ79aOyr3c5+fW2vDUlAoLLbMo > NNiTm470tmOgAhL8POol > =fE7h > -END PGP SIGNATURE- > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Package formats and software distribution on Linux
A while ago I participated in a discussion here about the debian package format. Quite recently I tried to spark up a discussion about package formats on the LSB list but did not get any replies, hopefully this discussion will be more welcome here. Constructive crticism is welcome, so feel free to critique. There is a sort of oligopoly in linux because of package management. There are several main distros which have a lot of package maintainers and a lot of packages as a result of this. Smaller distros need to choose between compatibility with existing packages and innovation (whatever that may be) - because creating and maintaining all of the packages you want to offer to the user is a very tedious task. This in turn limits the innovation these distributions could bring to the linux world and slows down the progress of Linux. A universal package format would benefit these distributions, since a lot less resources would have to be spent in order to create a new distribution. These small distributions will not be the only ones that benefit from this universal package format, big distributions such as debian will benefit from it too, because it will lift some weight off the maintainers' shoulders. Users of every distribution that supports such a format will obviously benefit from it since more software will be provided on their favourite distribution. And also ISVs will benefit from it, as it means less work for them to reach out to more users. However I'm not proposing to have a single true package format for all distributions. Rather my idea is to have a distribution-specific package format for packages that are distribution-specific, and a universal package format for packages that aren't specific. A lot of software applications, such as firefox, pidgin or openoffice do not require anything specific from a distribution like for example access to /etc/init.d/ files. Most simply require a certain library to be present or a certain dbus interface. This is what these packages really depend on, rather than the presence of other packages. Adding support for a universal package format will allow debian and other distributions to focus more on their real goals rather than on making packages from software which is already available on other systems. It will also allow distributions to make more invasive changes such as changing some functionality some other package may rely on, since currently, when two packages implement a certain interface other packages rely on, each of those packages has to have both of these packages specified in its dependencies. A transition from the current package format to the new package format could be gradual, with support for interfaces being added to the the distribution-specific package format first and then packages that do not rely on distribution-specific behaviour could gradually make a switch to the unified package format. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Re: Package formats and software distribution on Linux
I believe RPM is not suited well enough for this job, it tries to do everything rather than doing one thing and doing it well. The package format I'm proposing has a few features rpm does not. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Re: Package formats and software distribution on Linux
>Not to mention that the package format is not the only thing that matters. >It is the contents of the package, the rules, specs and standards that are >followed that cause the most differences. I aggree, and I'm hoping to resolve this issue >Oh and I guess I'm missing something, otherwise why wouldn't shipping rpm >and dpkg be enough to install either kind of packages? Because not all distributions are redhat or debian based. There are many others. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Re: Package formats and software distribution on Linux
> I've read that several times, but I still must be missing something. >My impression is that your poins is essentially the following: 1. it's >too much work for "small distros" to use any new format instead of one >of the big established ones; 2. let's reduce the number of big >established formats to one. No, on the contrary, I'm suggesting to have an additional format for software that is not system-specific and leaving the system-specific formats to do what they were designed for (i.e. manage system packages) rather than reducing the number of formats. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Re: Package formats and software distribution on Linux
Sorry for the delay, I've been very busy last week. >> A while ago I participated in a discussion here about the debian >> package format. Quite recently I tried to spark up a discussion about >> package formats on the LSB list but did not get any replies > >Can you point to the message (preferably via its Message-Id field) so we >can see what it was saying? http://lists.debian.org/debian-devel/2009/07/msg00978.html or b28b6cf70907310348x5d233eebgf7433398fd7f3...@mail.gmail.com >> hopefully this discussion will be more welcome here. Constructive >> crticism is welcome, so feel free to critique. > >To be honest, I'm not sure what response you expect to get. There's not >much substantive to respond to in your message: yes, it would be nice to >have a common package format, but I don't see what in particular you're >proposing be done about that. > >Such a discussion would IMO best be done at the freedesktop.org >distribution collaboration forum , >to gather input from the various distributions. Perhaps you could post a >more specific proposal there, and post here (and likely points in other >distribution-specific discussion forums) inviting interested parties to >join that thread. Thanks for the hint. I've posted the specification on the distributions mailing list. The spec can be found here: http://lists.freedesktop.org/archives/distributions/2009-November/000350.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
