Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository
]] Joachim Breitner Practically, I expect the intersection of those who want to use this package, and who need to have a different layout in /srv to be empty. So if I make the path configurable, it is adding complexity purely for policy compliance, and hence it is low priority for me. I would be interested in using the package and would be unhappy with the suggested default path (and there's no hard coded default you can come up with that will work, since I use host and domain names in /srv). (My plan for doing that is to have the authorative path in the local -apt-repository.path sytemd unit, which the admin can override using usual systemd foo, and can be read from the repository creating script.) That sounds perfectly fine. And, this looks like an interesting tool, thanks for taking the time to write it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository
* Joachim Breitner nome...@debian.org [150823 07:24]: With pow-priority, you mean one that does not get shown by default? But is that much better than allowing the interested admin to change the configuration afterwards? Actually, I was thinking it should be similar to postfix, which looks like it is using medium priority for most questions (sorry, that was my mistake). Note that my package does _not_ touch or put files in /srv. It merely uses files that are put in a certain directory that, that the admin has to create first. Does that mitigate your concerns? Somewhat. Still, it mandates that a specific directory in /srv be used. Current practice in Debian, based on a very small sample, is to use a subdirectory of /var, such as /var/www or /var/lib/pkgname. You would certainly be following precedent if you did something like this. However, after reading bug #775318 (CC'ed, as the rest of this message pertains to this specific package as well as the debian-policy bug), I am forming some new opinions. First, it now appears to me that the FHS authors: 1. intended for /srv to be used for things like this. 2. intended for the structure of /srv to be primarily under control of the local admin. 3. recognized that this directory was relatively new and best practices had not been established. They intentionally left the details unspecified to allow distributions to arrive at a consensus. In order for both distributions and local admins to safely share /srv, there must be some rules about how the namespace is divided. For /usr and /var, distributions were alloted all except one subdirectory of each: /usr/local and /var/local. This gives distributions primary control over these two top-level directories. To give local admins primary control of /srv, we should do the converse, and reserve one top-level subdirectory for distributions (perhaps /srv/pkg; other suggestions welcome), and leave the remainder of the /srv namespace available for the local admin. So you might use /srv/pkg/local-apt-repository. There currently does not appear to be any precedent in Debian for a package to use /srv as a default, so it would be nice for the first package to do so to get it right. Once packages start usurping top-level subdirectories of /srv, it will be difficult to ebb the tide. I do think that for packages where it makes sense to use a subdirectory of /srv, it also makes sense to ask the admin what directory to use, giving a sensible suggestion as a default. ...Marvin
Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository
On Sun, 23 Aug 2015 13:24:03 +0200 Joachim Breitner nome...@debian.org wrote: Hi Marvin, Am Samstag, den 22.08.2015, 16:47 -0400 schrieb Marvin Renich: I was under the (perhaps mistaken) impression that part of the purpose of /srv was to allow complete admin discretion with the directory structure, and that distributions were not to mandate any specific directory names. A low-priority debconf question asking the admin what directory to use, suggesting /srv/local-apt-repository, would satisfy that. If the question is not asked (or preseeded) the package would remain unconfigured. This would not be the only package to require explicit admin configuration to be operational, and the required configuration would be very minimal. (See below for an explanation of, why I think a debconf question would be better, though more complicated)) With pow-priority, you mean one that does not get shown by default? But is that much better than allowing the interested admin to change the configuration afterwards? Both apache2 and lighttpd use /var/www/html as the default directory to serve, and do not touch /srv automatically. I don't know of any Debian package that puts files in /srv. Note that my package does _not_ touch or put files in /srv. It merely uses files that are put in a certain directory that, that the admin has to create first. Does that mitigate your concerns? A problem, that I see with this, is that someone might already use /srv/local-apt-repository for something else. If that something is an apt repository (which is not unlikely with the given name) you might accidentally install files on your system, that weren't intended to be installed. With a debconf question, the admin is confronted with the fact, that this directory will be read, before doing so. If you don't want to do the debconf stuff, I offer to do it, as I have to get to know maintainer scripts and debconf anyway. Regards Sven
Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository
Hi Sven, Am Sonntag, den 23.08.2015, 18:18 +0200 schrieb Sven Bartscher: Note that my package does _not_ touch or put files in /srv. It merely uses files that are put in a certain directory that, that the admin has to create first. Does that mitigate your concerns? A problem, that I see with this, is that someone might already use /srv/local-apt-repository for something else. If that something is an apt repository (which is not unlikely with the given name) you might accidentally install files on your system, that weren't intended to be installed. I would expect that an admin would read the description of the package before installing it, and the description quite plainly tells him that this will happen. With a debconf question, the admin is confronted with the fact, that this directory will be read, before doing so. If you don't want to do the debconf stuff, I offer to do it, as I have to get to know maintainer scripts and debconf anyway. Thanks for the offer! If I have to do that, I’ll happily accept it. But I hope that there is a way to make this work out-of-the box, without the requirement of admin intervention and with a sensible default path. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository
Hi Marvin, Am Samstag, den 22.08.2015, 16:47 -0400 schrieb Marvin Renich: I was under the (perhaps mistaken) impression that part of the purpose of /srv was to allow complete admin discretion with the directory structure, and that distributions were not to mandate any specific directory names. A low-priority debconf question asking the admin what directory to use, suggesting /srv/local-apt-repository, would satisfy that. If the question is not asked (or preseeded) the package would remain unconfigured. This would not be the only package to require explicit admin configuration to be operational, and the required configuration would be very minimal. With pow-priority, you mean one that does not get shown by default? But is that much better than allowing the interested admin to change the configuration afterwards? Both apache2 and lighttpd use /var/www/html as the default directory to serve, and do not touch /srv automatically. I don't know of any Debian package that puts files in /srv. Note that my package does _not_ touch or put files in /srv. It merely uses files that are put in a certain directory that, that the admin has to create first. Does that mitigate your concerns? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository
Package: wnpp Severity: wishlist Owner: Joachim Breitner nome...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: local-apt-repository Version : 0.1 Upstream Author : Joachim Breitner nome...@debian.org * URL : http://anonscm.debian.org/cgit/collab-maint/local-apt-repository.git/ * License : MIT Programming Lang: Bash Description : Ready to use local apt repository With this package installed, every Debian package (i.e. a *.deb file) dropped into /srv/local-apt-repository (which you need to creat first) will be available to apt. This package does not provide an apt repository to be used by other hosts. For that, look at more serious repository solutions like reprepro and apt-ftparchive. This package also tries to use the nice features provided by systemd, in this case path-monitoring and system activiation via path changes, so that the repository is recreated as soon as the user drops a package there. The repo is already on alioth and in a working form; it seems that just cgit is not yet aware of it. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlXYY+IACgkQ9ijrk0dDIGzZKACfT6tmZ0ZOOwzpFKXDwNmYfNqC GkMAnjKsYbZZae98nB3XS7ZE5+5hZRSE =hypH -END PGP SIGNATURE-
Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository
* Joachim Breitner nome...@debian.org, 2015-08-22, 13:58: With this package installed, every Debian package (i.e. a *.deb file) dropped into /srv/local-apt-repository Sounds like an FHS violation: “no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv.” (which you need to creat first) Typo: creat - create -- Jakub Wilk
Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository
Hi Jakub, Am Samstag, den 22.08.2015, 14:54 +0200 schrieb Jakub Wilk: * Joachim Breitner nome...@debian.org, 2015-08-22, 13:58: With this package installed, every Debian package (i.e. a *.deb file) dropped into /srv/local-apt-repository Sounds like an FHS violation: “no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv.” this was just discussed on IRC. Here is my rationale: Packages to be added to the repository fit the description of /srv quite perfectly. I quote. /srv : Data for services provided by this system Purpose /srv contains site-specific data which is served by this system. This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users' home directory. [..] So it is not wrong to use this directory. Also, all alternatives are wrong in some way as well. The only thing that I’m currently doing wrong is that I hard-code the path (“Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv.”). If the package would make the path configurable, then it’d be in compliance with the FHS. Practically, I expect the intersection of those who want to use this package, and who need to have a different layout in /srv to be empty. So if I make the path configurable, it is adding complexity purely for policy compliance, and hence it is low priority for me. (My plan for doing that is to have the authorative path in the local -apt-repository.path sytemd unit, which the admin can override using usual systemd foo, and can be read from the repository creating script.) Greetings, Joachim -- -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository
* Joachim Breitner nome...@debian.org [150822 09:04]: Hi Jakub, Am Samstag, den 22.08.2015, 14:54 +0200 schrieb Jakub Wilk: * Joachim Breitner nome...@debian.org, 2015-08-22, 13:58: With this package installed, every Debian package (i.e. a *.deb file) dropped into /srv/local-apt-repository Sounds like an FHS violation: “no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv.” this was just discussed on IRC. Here is my rationale: Packages to be added to the repository fit the description of /srv quite perfectly. I quote. /srv : Data for services provided by this system Purpose /srv contains site-specific data which is served by this system. This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users' home directory. [..] So it is not wrong to use this directory. Also, all alternatives are wrong in some way as well. I was under the (perhaps mistaken) impression that part of the purpose of /srv was to allow complete admin discretion with the directory structure, and that distributions were not to mandate any specific directory names. A low-priority debconf question asking the admin what directory to use, suggesting /srv/local-apt-repository, would satisfy that. If the question is not asked (or preseeded) the package would remain unconfigured. This would not be the only package to require explicit admin configuration to be operational, and the required configuration would be very minimal. Both apache2 and lighttpd use /var/www/html as the default directory to serve, and do not touch /srv automatically. I don't know of any Debian package that puts files in /srv. While I agree that having a service fully functioning immediately after installation is usually a desirable goal, I believe that it is more important to not interfere with an admin's authority. The /var/local directory was needed so admins had a directory that was guaranteed to not be stepped on by the package manager. If we start letting packages put things in /srv, then we may end up needing /srv/local for the same reason, when /srv should already serve that purpose. ...Marvin
Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository
On السبت 22 آب 2015 13:47, Marvin Renich wrote: So it is not wrong to use this directory. Also, all alternatives are wrong in some way as well. I was under the (perhaps mistaken) impression that part of the purpose of /srv was to allow complete admin discretion with the directory structure, and that distributions were not to mandate any specific directory names. I've brought this issue up before to the Debian policy. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775318 -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
